undefined | Better HN

0 pointswiz2110y ago0 comments

That's a very insightful comment. I 100% agree. And I'd add that I'm still completely baffled to see that some very obvious data support issues are still not resolved in the industrial world (e.g Java) : * Computing with units (which is tough to put in a language, but so is compilation) * Computing with dates in a sensible way

Of course one can make computation on those types, but it is so un-natural that it scares me :

* BigDecimal for currency, let me laugh * Date/timestamp without proper casting rules * Types towers with inheritance, generics, etc. Pfff... * Still no fine library to represent an address * Representing mutable ordered lists in SQL databases is still quite painful (possible, sure, but there's so boiler plate code to write)

So the data representation/manipulation problem, which goes with the data longevity you observe, that's something to learn about...

There's no reason to love current programming languages :-( (but I do love Python :-) 3 of course :-))

0 comments

EdwardDiego10y ago

> Computing with units (which is tough to put in a language, but so is compilation

F#'s units are nice.

> Computing with dates in a sensible way

The new Java time API is pretty good. But honestly my favourite datetime API would have to be Postgres'.

> BigDecimal for currency, let me laugh

Out of curiosity, why?

wiz21OP10y ago

For F#, I didn't know. It looks verrrrrry sweet.

For BigDecimal, my grief is that it makes code horrible (at least in my experience, I'm still locked in JDK 1.7).

BigDecimal has the problem I see with the rest of my griefs : it is possible to compute things correctly with code (obviously), but the way the code is written is ugly (and painful).

   BigDecimal yearly_amount = new BigDecimal("1000.00"); 
   BigDecimal daily_amount = yearly_amount.divide(new BigDecimal("12")); // Beware the rounding issue

Wouldn't it be nicer if :

   money<4> yearly_amount = 1000.00 EUR; // 4 decimals 
   money<2> daily_amount = yearly_amount / 12; // Beware the rounding issue !

Of course, this notation doesn't help much with rounding, but at least it makes the code easier to read. And trust me, using BigDecimal, doesn't prevent many people of making mistakes with rounding.

EdwardDiego10y ago

True, but it can do, if you set precision etc.

nightski10y ago

I fell in love with Haskell for quite some time. In fact, I still really enjoy the language. But after a while I noticed that I was not in love with Haskell itself but some of the things it brings to the table which are very important. Sure there may be new languages in 50 years in the mainstream, but let's hope we learn from our past successes and failures. In that sense, it pays to care about languages today as they will directly impact the future.

If we all give up and just use mainstream languages, then the future will be filled with copies of mainstream languages.

j / k navigate · click thread line to collapse

0 pointswiz2110y ago0 comments

Of course one can make computation on those types, but it is so un-natural that it scares me :

So the data representation/manipulation problem, which goes with the data longevity you observe, that's something to learn about...

There's no reason to love current programming languages :-( (but I do love Python :-) 3 of course :-))

0 comments

EdwardDiego10y ago

> Computing with units (which is tough to put in a language, but so is compilation

F#'s units are nice.

> Computing with dates in a sensible way

The new Java time API is pretty good. But honestly my favourite datetime API would have to be Postgres'.

> BigDecimal for currency, let me laugh

Out of curiosity, why?

wiz21OP10y ago

For F#, I didn't know. It looks verrrrrry sweet.

For BigDecimal, my grief is that it makes code horrible (at least in my experience, I'm still locked in JDK 1.7).

BigDecimal has the problem I see with the rest of my griefs : it is possible to compute things correctly with code (obviously), but the way the code is written is ugly (and painful).

   BigDecimal yearly_amount = new BigDecimal("1000.00"); 
   BigDecimal daily_amount = yearly_amount.divide(new BigDecimal("12")); // Beware the rounding issue

Wouldn't it be nicer if :

   money<4> yearly_amount = 1000.00 EUR; // 4 decimals 
   money<2> daily_amount = yearly_amount / 12; // Beware the rounding issue !

Of course, this notation doesn't help much with rounding, but at least it makes the code easier to read. And trust me, using BigDecimal, doesn't prevent many people of making mistakes with rounding.

EdwardDiego10y ago

True, but it can do, if you set precision etc.

nightski10y ago

If we all give up and just use mainstream languages, then the future will be filled with copies of mainstream languages.

j / k navigate · click thread line to collapse