Live data from Hacker News

The Developer's Dystopian Future

the-pastry-box-project.net

201–209 of 209 posts

Re: The Developer's Dystopian Future

#201
post #145

Earlier quoted context omitted.

Ignoring the joy of writing software with much more powerful abstractions for a moment (Python, Ruby, JS, PHP all look like jalopies now compared to Haskell) out has very real industrial benefits: Write software faster with fewer bugs, easier to maintain down the road because the "mental model" is maintained in the types by the compiler, it's more succinct, it's fast, some of the world's brightest computer scientists…

Thanks for your response. I'd like to dive a little deeper into the basis for these claims. My current stance is that there isn't sufficient reason to adopt Haskell for use in production. > Write software faster with fewer bugs Is there an evidentiary basis for the 'fewer bugs' claim? What type of software are people writing faster with Haskell? >> easier to maintain down the road because the "mental model" is mainta…

>> Write software faster with fewer bugs > Is there an evidentiary basis for the 'fewer bugs' claim? What type of software are people writing faster with Haskell?

http://donsbot.wordpress.com/2007/05/01/roll-your-own-window... and especially http://donsbot.wordpress.com/2007/05/17/roll-your-own-window... give a good introduction into the mindset behind programming in Haskell.

The latter focusses on zippers. Zippers solve the problem of having a connection and a `cursor' into that connection to mark one element--in the case of XMonad we mark the window that has focus.

In C you would probably solve this with an array and an int. Unfortunately, the compiler can't help ensure that your int always points into the array, and that deleting and inserting are doing the right thing. Zippers help here.

Re: The Developer's Dystopian Future

#202
post #193

Earlier quoted context omitted.

> Ignoring the joy of writing software with much more powerful abstractions for a moment (Python, Ruby, JS, PHP all look like jalopies now compared to Haskell) Just out of curiosity: Which abstractions are we talking about here that Haskell doesn't have? OO?

I didn't write that sentence very well if that's how it was interpreted, sorry. I meant to say that the abstractions available to Haskell are more powerful. I can't really think of any abstraction that's not available to it - even an Object System is possible in Haskell, it just wouldn't be as easy to use as Monads are.

> I can't really think of any abstraction that's not available to it [...]

Dependent typing doesn't work very well in Haskell (yet).

Re: The Developer's Dystopian Future

#203
post #109

Earlier quoted context omitted.

Relax. A lot of those technologies will be dead. And you should be intimidated by angular and ember. They have the smell of Enterprise Java for me. Learn paradigms and principles. If you know what to do, you will be able to find the tools to do it. Its a bit like cooking - the cookbooks for the peasants give recipes. The ones for the chefs give mechanics and techniques. So learn pointers, functional programming, asyn…

AngularJS and Ember can be intimidating if you've never: A) Built an API B) Used an MVC Framework (front or back end) This can be easily overcome by following either a book like "AngularJS in Action" or spending some time using a framework on a small scale project. At the end of the day, I've found that when using Angular, my code is much easier to read, maintain, and reason about. I used it for one project about a y…

I find these kinds of frameworks intimidating, because in them there is usually a ??magic?? phase that is difficult to debug if it does not work.

Re: The Developer's Dystopian Future

#204
post #145

Earlier quoted context omitted.

Ignoring the joy of writing software with much more powerful abstractions for a moment (Python, Ruby, JS, PHP all look like jalopies now compared to Haskell) out has very real industrial benefits: Write software faster with fewer bugs, easier to maintain down the road because the "mental model" is maintained in the types by the compiler, it's more succinct, it's fast, some of the world's brightest computer scientists…

Thanks for your response. I'd like to dive a little deeper into the basis for these claims. My current stance is that there isn't sufficient reason to adopt Haskell for use in production. > Write software faster with fewer bugs Is there an evidentiary basis for the 'fewer bugs' claim? What type of software are people writing faster with Haskell? >> easier to maintain down the road because the "mental model" is mainta…

Interesting you should ask for more verification of my claim to fewer bugs because I'm about to embark on using Haskell in the new startup I'm working for and they may require stronger reasoning than I have been providing.

I've been thinking about how to qualify the claim logically or maybe quantify it. Anywho, aside from that I can tell you that the vast majority of bugs I introduce into my Python code (or other languages) are caught by GHC - these are bugs that purely have to do with my inability to remember what something is or is doing, or fear of refactoring something, or some tangled mess of types that are harder to reason about in Python because they're in my head instead of encoded in Haskell.

I've discovered that when I've been able to compile my Haskell programs the bugs I find in them are usually business logic bugs now. Occasionally I'll make use of QuickCheck / HUnit for automated property testing and unit testing, and that will help catch those business logic bugs.

Very subjective and anecdotal but I can promise you that the experience is very real.

> In isolation, that's a bit hand wavy IMO.

Sure, but if you take into account Haskell's denotational semantics vs. other language's operational semantics it should be pretty clear that Haskell inherits Mathematic's idiom for succinct expression. That idiom also informed the language designers when building Haskell's grammar and syntax, it's very flexible and abstract - both in the essence of the language (it's semantics) and its modality.

When reading idiomatic Haskell, there's a lot of information packed into a line, conceptually and syntactically.

> This is something I hear quite often from the Haskell community...

Sure, it probably borders on it, but in many ways other language communities commit the bandwagon fallacy (Go is one) - so I think you can poke holes all over the place. The fact though that proof proving systems and dependently typed languages like Agda and Idris (which are the future and I think will supplant Haskell unless Haskell can evolve) are being written in Haskell which speaks to the level of intellect and forward thinking in the community.

Re: The Developer's Dystopian Future

#205

Earlier quoted context omitted.

They may come and go in the small bubble of blogs you read, but the real world works very differently. Heck, I work with Perl on a regular basis. Not for some amateur web pages but for real, important, back end stuff. What matters is that the code is solid, not how many new blogs are started on the subject. Remember that the ones who get things done in the world does not blog about it. No blogs chronicled how they ch…

> Remember that the ones who get things done in the world does not blog about it. Perhaps not necessarily true. I don't blog as often as I used to but I still get things done. The act of writing helps to strengthen and reinforce good ideas and train one to recognize them in the future. Publicly or privately matters little... but some of us do "blog."

I think your parent's language was a bit inflammatory, but I like the reminder that not everybody doing interesting things is blogging and tweeting about it. Lots of people just work.

Re: The Developer's Dystopian Future

#206

Earlier quoted context omitted.

I reminded a co-worker last week as he was figuring out whether to use Grunt or Gulp - Computers aren't the thing. They're the thing that gets us to the thing. - Quoted from Halt and Catch Fire. Photography has its own version of the same quote. Amateurs worry about equipment, Professionals worry about time, Masters worry about light. User do not care about the technology used, they care about results.

Same thing bro with musicians, "Amateurs are gear-heads, pro's worry about techniques, and masters tries to listen to the sound"; traders/gamblers, "Amateurs focus on their winning, pro's worry about preserving their capital and masters worry about executing their performance where losing and winning money is only a side effect," and ad infinitum.

Reminds me of the Freaks and Geeks episode where he goes to a drumming audition and gets made fun of a bit for his enormous kit before completely bombing.

Re: The Developer's Dystopian Future

#207
post #143

Earlier quoted context omitted.

In the context of noname123's post they bring interesting learning to the table: they are not more of the same with renamed keywords. To quote, > [...] it's not like learning music and digging into a deeper discipline like moving from acoustic strumming to jazz improvisation, it's just learning new keywords to do the same crap because the old keywords have been remapped. Haskell _is_ digging deeper into the disciplin…

How do you Haskell on embedded systems? Are you talking about baremetal with 1-32K SRAM?

To take this thread yet further into self-parody, you might like Rust; it borrows some interesting stuff from Haskell (or really, the ML family), but is actively targeting embedded systems.

Edit: Also, I have heard that Ocaml can be made to work pretty nicely in an embedded environment.

Re: The Developer's Dystopian Future

#208

Earlier quoted context omitted.

How do you Haskell on embedded systems? Are you talking about baremetal with 1-32K SRAM?

To take this thread yet further into self-parody, you might like Rust; it borrows some interesting stuff from Haskell (or really, the ML family), but is actively targeting embedded systems. Edit: Also, I have heard that Ocaml can be made to work pretty nicely in an embedded environment.

You can make OCaml (and Haskell) run on Xen, no need for a full blown operating system. (Not sure if that counts for anything.) The OCaml project for that is called mirage.

Re: The Developer's Dystopian Future

#209
post #31

Earlier quoted context omitted.

I used to have that passion, when I was young (I'm 29 now, so not very young for the tech world, although not old either). And to be honest, it was the 40+ work week what killed it. I never liked specialization, so to me it makes a lot of sense that, if you're already investing that much time in technology, you may spend the rest of the week doing a different thing. I'm getting a new degree (in principle, I don't pla…

I think the tech industry discounts the value of expanding your horizons. I have a background in design and writing, and when I choose to incorporate those disciplines into what I do with code, a lot of magic happens. Let's say I order a class like a do a news article (upside down pyramid, aka most important shit first). Or I apply my own design eye to the motion or interactivity of a static design. Or even to how I…

> I think the tech industry discounts the value of expanding your horizons. I have a background in design and writing,

I had a developer get up in my face once and chew me out for studying design in my spare time instead trying more new languages and frameworks because I'm a developer, dammit, and it should be all I live, eat, and breathe.

That's bull. Well-rounded people bring a lot to teams, the least of which being the ability to speak to other specialties in a common language.

Keep broadening your horizons & keep being awesome.

Post reply on HN