51–60 of 128 posts
Something Haskell programmers commonly experience is that their programs typically work the first time they compile, due to the type system. I was skeptical of this but I've experienced it myself too -- it's kind of fun! What this means is that you spent most of your time thinking about how to express your code elegantly in the type system, but once you do it usually just works. That's a huge practical benefit you do…
Earlier quoted context omitted.
I feel like this is something that people who use a certain language repeat to themselves until they believe it. Go is big enough that this certainly doesn't hold for tens of thousands of developers.
In my experience Go's relatively constrained language and standard library coupled with gofmt mean Go code written by entirely different people tends to read fairly consistently.
Earlier quoted context omitted.
This is generally true. > From a business perspective, any language is arbitrary. Counterpoint: And then when the company starts growing quickly and has to hire 10 Haskell devs in 12 months, they realize its pretty much impossible to do without shelling out $200k/person.
...which is likely saving money long run anyway - good developers usually pay for themselves, if not, they're in the wrong place.
I’ll come out and say it though: Haskell is a cult. It’s best to smile and nod when you’re around the believers. They’re harmless. Ditto for rust.
It is truly astonishing how much code a determined team of haskellers can produce. I’ve been porting a codebase, line by line, to python. I’m up to 15 thousand lines.
Had to do it without being able to run the program too.
There are lots of benefits. (Ditto for being in a cult.) It’s worth knowing what they are, since they are powerful. But (hello cult) there are plenty of negatives; monads are the Aristotle philosophy equivalent of programming. Take care not to study them too closely.
Earlier quoted context omitted.
This is where I differ. I think the Python/JS/Go crew gets you stuff that is built poorly and becomes expensive to maintain. I much prefer the JVM and ASP.NET crew because they are 9-5 programmers, their tools aren't constantly changing so for the most part they only need to spend time actually doing work. No fighting with package managers, no updating the latest framework and solving backwards incompatibilities for…
> I much prefer the JVM and ASP.NET crew because they are 9-5 programmers, I don't think thats what the parent meant. They meant esoteric functional programming languages vs mainstream OOP ones. You're saying the same thing.
The former is old, boring and sticks to what works. They are both slow moving, have large established frameworks for each applicable domain, prioritize backwards compatibility, have highly evolved IDEs that support both the language but also the dominant frameworks etc.
The latter are easy to learn, emphasize the easy creation of new applications and libraries, move quickly/rapidly adopt new language and runtime features, don't generally care much for backwards compatibility in the library ecosystem, have many competing frameworks and libraries for everything. etc.
They are just very very different and as a result produce very different codebases that have very different tradeoffs in hiring, maintainence costs, development velocity, pivotability etc.
Sometimes those languages are the right tool for the job but IMO mostly in cases where you aren't sure what that job is. If you already know what you want to build and how to build it then the "boring" tech stack is generally the way to go in my experience.
I like the separation between pure and impure code. In his Haskell class Eric Meijer said that pure code are like islands and monadic code is like the ocean, and as programmers we decide how much of a system is pure code. Sorry for being off topic: the new M1 Macs seem to take some of the pain out of large runtimes for compile/build in languages like Haskell and Swift. I don’t have any benchmarks, this is just very n…
If not, can you share a link? Thanks!
Earlier quoted context omitted.
Can you give an example of what kind of boilerplate you mean? Because I feel like modern Java and Kotlin have improved a lot in this area.
"Code to interfaces instead of implementations" type boilerplate Code that doesn't do anything except support a design pattern you're following is boilerplate.
There's nothing in the languages themselves that forces you to use inappropriate design patterns, and as the parent mentions, modern Java and Kotlin have improved a ton in reducing boilerplate. I'm not actually sure what it is that you think they're missing that Python or JavaScript have, unless it's just that you prefer dynamic typing.
Earlier quoted context omitted.
> If you are prototyping extremely quickly then maybe Ruby on Rails might be the right tool for the job (and thus attract the right kind of people). I am puzzled by this because my early experience of Ruby On Rails (and I mean early -- 2005) is that every Rails developer I encountered knew much less than they were letting on. > Go attracts mediocrity and not in a good way, it also actively repels the "right " people…
For context I worked with Go extensively for about 5 years. I tried very hard to like it because I have immense respect for folks on the core team. I even wrote some pretty good code in it. However a few things became very clear to me over time. 1. Go is -not- a general purpose language. It lacks expressiveness necessary for this purpose which leads to overly hard to follow and refactor business logic, repetitive and…
No -- this is interesting. I also think point 3 and 5 probably informed and explain the new generics design, which seems intended to reward perseverance.
I didn't find channels difficult, but then I have some Occam, CSP and PVM experience, and some message-passing parallel language design experience too (albeit all academically, including 27 years ago in my final degree assignment)
Binary size is small..
And very important to me they could be executed even years after they were first uploaded to Rosetta code.
A very good study and the researches gave an entertaining talk on it, that I can't find now.
Earlier quoted context omitted.
> I think the Python/JS/Go crew Genuine question: are these people a crew? I doubt very much each individual constituency in that trio would think so. JS and Go are really very different things with different mindsets. Python vs JS likewise.
No, it just means the people that tend to be attracted to these types of languages. Easy to get started languages that hide much of the inner workings from you as a dev.