Earlier quoted context omitted.
Don't worry, I'm still here.
Yes, but are you still the lead? :)
I'm still the lead.
How we secretly introduced Haskell and got away with it
41–50 of 188 posts
Re: How we secretly introduced Haskell and got away with it
#42While it's an interesting look at a change you introduced, that blog title might not come across quite as intended.
If you're having to "secretly introduce" tech, and "get away with it", that suggests there are unnecessary and unproductive constraints on your work; maybe even suggesting that you'd get in trouble for actually daring to make things better.
Re: How we secretly introduced Haskell and got away with it
#43In the 1990s I did research on the efficacy claims of object oriented programming versus procedural programming. This article bares a striking resemblance in the claims. Case study after case study showed that object oriented code had less bugs due to compilers catching bugs, etc. However, almost every study was similar to this report: it was a re-write from procedural to object-oriented. There exists strong evidence…
Sounds right. Additionally, they didn't even reimplement what they had, the article gives the impression that they basically gave up on trying to reinvent relational query optimization ("We heavily modified pyDatalog to query Redis as its knowledge base") and focused on just solving the problem at hand.
Re: How we secretly introduced Haskell and got away with it
#44Earlier quoted context omitted.
There is another aspect. Changing languages. Rewriting in a language that is sufficiently different from the original forces you to look at the problem with new eyes. You effectively have greater mental coverage of the problem domain.
Articles like: We switched from language X to language Y with the conclusion that language Y is better smile My favorite is when they make another post half a year later saying they changed from Y to Z. It seems that following the trend and using the latest and greatest tools doesn't necessary mean the new tools are better, but that you got to rewrite your applications from scratch, with much more knowledge about the…
LinkedIn: Our iOS app is web-based! Simple and fast! We save money!
2 years later...
LinkedIn: Our iOS app is native! Simple and fast! We save money!
Re: How we secretly introduced Haskell and got away with it
#45"It is said that Haskell programmers are a rare species, but actually the majority of developers at Channable had used Haskell before."
Could you imagine if this wasn't the case? The hurdle to actually get people excited about a language such as Haskell especially moving from something like Python would potentially be huge. Kudos for already having that problem solved.
Re: How we secretly introduced Haskell and got away with it
#46Earlier quoted context omitted.
There is another aspect. Changing languages. Rewriting in a language that is sufficiently different from the original forces you to look at the problem with new eyes. You effectively have greater mental coverage of the problem domain.
Articles like: We switched from language X to language Y with the conclusion that language Y is better smile My favorite is when they make another post half a year later saying they changed from Y to Z. It seems that following the trend and using the latest and greatest tools doesn't necessary mean the new tools are better, but that you got to rewrite your applications from scratch, with much more knowledge about the…
> My favorite is when they make another post half a year later saying they changed from Y to Z.
Sometimes I wonder if the real subtext is "we have such high turnover that almost nobody was around when the first system was designed. We rewrote it in a new language, and now we're all much happier because we all understand it much better, having been involved in its design." Wait a year, repeat.
Re: How we secretly introduced Haskell and got away with it
#47While it's an interesting look at a change you introduced, that blog title might not come across quite as intended. If you're having to "secretly introduce" tech, and "get away with it", that suggests there are unnecessary and unproductive constraints on your work; maybe even suggesting that you'd get in trouble for actually daring to make things better.
Not the author, but I think that is exactly what they wanted to convey in the title. The implication is that they're fighting the man and won.
There's a tradition of programmers laying claim to subversively Making Things Better in spite of the bean counters. Sometimes, it is even true, as far as it goes.
Re: How we secretly introduced Haskell and got away with it
#48Earlier quoted context omitted.
The whole "Do you have the dependencies and a Python env installed? Noß Then you can't run this script/program." was one of the main reasons I switched from Python to Rust, where cargo as the (very good) package manager comes with the language and, because Rust is a compiled language, you build all the dependencies into your executable you aren't dependent(heh.) on the user having installed a runtime that maybe or ma…
I guess this is true if you don't need to interact with any system libraries.
Could you give an example of what "system libraries" would pose a problem in my example of using Rust with cargo?
Also note that by "no runtime installed" I mean no runtime as in "no Python runtime", "no JVM" etc. not necessarily "no libc"
EDIT: formatting
Re: How we secretly introduced Haskell and got away with it
#49In the 1990s I did research on the efficacy claims of object oriented programming versus procedural programming. This article bares a striking resemblance in the claims. Case study after case study showed that object oriented code had less bugs due to compilers catching bugs, etc. However, almost every study was similar to this report: it was a re-write from procedural to object-oriented. There exists strong evidence…
Given the awfulness of so many OOP-based frameworks that I encountered in the 90s, I began to seriously consider that OOP wasn't a better paradigm for most things and that instead it was worse, and simply caused people to rewrite code to the point that it overcame the procrustean bed of inheritance and whatever other tools the language of choice was providing.
Re: How we secretly introduced Haskell and got away with it
#50In the 1990s I did research on the efficacy claims of object oriented programming versus procedural programming. This article bares a striking resemblance in the claims. Case study after case study showed that object oriented code had less bugs due to compilers catching bugs, etc. However, almost every study was similar to this report: it was a re-write from procedural to object-oriented. There exists strong evidence…
Wouldn't a complete rewrite of a module usually be a lot easier if the program is procedural? I think that is one of the big factors stopping that from actually happening with OO code. A rewrite is a lot harder if you tap into what exists elsewhere in the codebase. I bet you have a lot more insight into this than me though.
I'm not so sure about that. I think a complete rewrite is easier if you correctly separated concerns and compartmentalized needs. OOP is supposed to enforce/encourage that, but it's fairly easy to not treat your objects as black boxes with APIs, and then you've put constraints on replacing a component. Procedural code doesn't necessarily tout it's ability to encourage that, but well planned and implemented functions can give you the same benefit.
In the end, it's all up the the programmer.