Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Haskell is our first choice for building production software systems

foxhound.systems

Post reply on HN
Print view View original

291–297 of 297 posts

Re: Haskell is our first choice for building production software systems

#291

Post by secondcoming »

nicoburns wrote: post #279
secondcoming wrote: post #271

Earlier quoted context omitted.

Interesting point. I'd never have believed it myself, but find myself using acronyms instead of variable names when the type allows it. void foo(MyType mt, const MyOtherType& mot); It's the variable names that are the noise, types are everything. And no, it's not Hungarian notation either in case anyone suggests it! However, it maybe doesn't work that well with things like class member names. YMMV

I guess it partly depends on how varied your types are. In some domains you can find yourself working with 10 variables that are all strings, or all floats/integers. At that point the type isn't that helpful for distinguishing which variable is which.

I should have added that fairly liberal use of type aliases also helps.

    using B64String = std::string;

    B64String encode(const std::string& text);
    std::string decode(const B64String b64);

Re: Haskell is our first choice for building production software systems

#292

Post by WraithM »

bcrosby95 wrote: post #240
WraithM wrote: post #146

Earlier quoted context omitted.

I appreciate that you wrote that you "feel" more productive with python. I 100% agree with this feeling at most scales of code size, and the feeling matches reality at the small scale. However, I've found that this feeling of productivity doesn't match reality in the large. I use Haskell for programming in the large despite this feeling of unproductivity, because in fact, I am way more productive.

> in the large At what point do you feel like this line is crossed? "In the large" can mean different things to different people.

100k+ lines

Re: Haskell is our first choice for building production software systems

#293

Post by hardwaresofton »

throwaway894345 wrote: post #288
hardwaresofton wrote: post #287

Earlier quoted context omitted.

I think saying "packages" was an error on my part, because how this is different from the usual C++/other language example is that Haskell is a ML language, and gives you a lot of abstractions (rather than packages per say) to use. Generally using packages in haskell is easy because you don't care what abstraction they were written in (almost always IO is there somewhere, or they offer a doTheThingIO function which i…

Well said; thanks for the explanation.

No problem,I am not an expert in the space but there are just my feelings on haskell.

Let's see if FoxHound is around in 1-3 years :)

Re: Haskell is our first choice for building production software systems

#294

Post by jhayward »

Rusky wrote: post #281
jhayward wrote: post #257

Earlier quoted context omitted.

I got the idea by following the Rust tutorials and then making 'simple' programs, seeing the errors, going to Rust resources and getting the advice 'just cut and paste the expected type'. The expected types generally had 6-8 ':'s, and three to four deep nested type specifiers.

If a significant part of those types was just something like `std::collections::` or similar then I'm not sure I see the problem. Suggestions should probably trim redundant prefixes like that, but recognizing standard library namespaces shouldn't be a big obstacle to understanding either.

I haven't been back to rust since, so I don't have the specifics. But it was clear to me that this was not a helpful way to program.

It was also crystal clear that, like C++, Rust puts many barriers to true abstraction. You have to know many, many details of how a specific type is implemented, sometimes several levels deep, to correctly use it at a high level. The cognitive overhead is enormous.

Re: Haskell is our first choice for building production software systems

#295

Post by thesz »

andrekandre wrote: post #272
thesz wrote: post #209

Earlier quoted context omitted.

C++ cannot have non-local type inference due to, you know, object-oriented part of it. This means that you cannot say something like this: auto sepulka; auto bubuka = zagizuka(sepulka); Because if zagizuka's parameter is a structure or a class, you have a selection of parents. On a contrary, you have a selection of descendants of the result type of zagizuka() for bubuka, each having their own copy or assignment const…

not that im advocating it per se, but couldnt you deduct the tyope based on what `zagizuga()` does with `sepulka`? for example def sepulka(zagizuga) zagizuga.doSomething() zagizuga.doSomethingElse() would infer the type of zagizuga as some object that implements two methods `doSomething()` and `doSomethingElse()`... i think that should be doable (and possibly extremely slow) right? maybe i missed something...

Yes, it is doable, but what if there several memory-layout incompatible classes which implement both methods?

E.g, A implements virtual doSomething() and B and C inherit from A, add some different fields and both implement doSomethingElse() which they should overload for their inheritance from class Z.

Re: Haskell is our first choice for building production software systems

#296

Post by Rusky »

jhayward wrote: post #294
Rusky wrote: post #281

Earlier quoted context omitted.

If a significant part of those types was just something like `std::collections::` or similar then I'm not sure I see the problem. Suggestions should probably trim redundant prefixes like that, but recognizing standard library namespaces shouldn't be a big obstacle to understanding either.

I haven't been back to rust since, so I don't have the specifics. But it was clear to me that this was not a helpful way to program. It was also crystal clear that, like C++, Rust puts many barriers to true abstraction. You have to know many, many details of how a specific type is implemented, sometimes several levels deep, to correctly use it at a high level. The cognitive overhead is enormous.

In Rust's target domain(s), those details often turn out to be quite relevant.

Hiding them basically amounts to targeting a different domain. This is very different from being irrelevant and noisy.

Re: Haskell is our first choice for building production software systems

#297

Post by andrekandre »

thesz wrote: post #295
andrekandre wrote: post #272

Earlier quoted context omitted.

not that im advocating it per se, but couldnt you deduct the tyope based on what `zagizuga()` does with `sepulka`? for example def sepulka(zagizuga) zagizuga.doSomething() zagizuga.doSomethingElse() would infer the type of zagizuga as some object that implements two methods `doSomething()` and `doSomethingElse()`... i think that should be doable (and possibly extremely slow) right? maybe i missed something...

Yes, it is doable, but what if there several memory-layout incompatible classes which implement both methods? E.g, A implements virtual doSomething() and B and C inherit from A, add some different fields and both implement doSomethingElse() which they should overload for their inheritance from class Z.

good question, i guess it depends on the language... multiple inheritance without namespacing would either result in either method getting chosen randomly, or a build error...

for example, in swift you cant even inherit from two protocols that have default implementations... and i think in c++ you also cant call the method without specifying namespace...

so, i suppose, if you wanted to go all the way, you could even do namespace inference

  def sepulka(zagizuga)
    zagizuga::Something.doSomething()
    zagisuga.doSomethingElse()
so zagizuga is infered to be some type that inherits from `Something` namespace and expects that namespace to defined `doSomething()` function, in addition to providing `doSomethingElse()`

though that seems getting a bit fragile irl maybe...

Post reply on HN