241–250 of 320 posts
Which it always has been, whether outsourcing to cheap "talent" overseas, or now a subscription service text generator.
The article makes a convincing argument that Haskell compilation is too slow for the fast code generation of AI. But python? I have yet to experience a RHEL major version change that did not blow up all my tiny simplistic python scripts. I see the following options for using python: * run inside the container it was developed in * build your own python interpreter and environment and libraries and never use python pi…
Earlier quoted context omitted.
Recently had to touch a Python project at work. Just setting up the editor needed me to use 2-3 tools out of: pyright, basedpyright, ruff, ty, mypy, and possibly other tools I'm forgetting that kind of do the same thing but throw errors in different parts of the codebase. Also, for some reason Optional[T] became deprecated, just as the ecosystem finally embraced types ~3 years ago. In fact, one my company's greenfiel…
(Note: I work on Python tooling.) > for some reason we need 2-3 static analysis tools just for typechecking I don’t follow: you need one type checker, of which you have several options. It’s arguably not ideal to have more than one option, but you should never need to run more than one. - no tool understands each other's comment directives In general, all type checkers in Python support the `type: ignore` directive,…
It's a complete ergonomic travesty that Python doesn't have one.
Earlier quoted context omitted.
Right, they run tests too. A compiler is like a quick test before tests. How are you going to cut out that check and let the LLM "write it faster" is beyond me. The compiler catches errors across codebases that today's LLM can't economically or reliably put into context to perform similar checks. They're totally different tools, today. Also, you can just compile less frequently. But hey, if LLMs are what drove this p…
> But hey, if LLMs are what drove this person from Haskell to Lisp then all the power to them! I didn't see Lisp mentioned in the article. They moved to Python. Which is certainly a choice.
Earlier quoted context omitted.
cabal hell isn't even a real thing anymore.....
I only use Haskell in hobby projects outside of work but somewhat regularly run into problems with package bounds causing conflicts or forcing some project on to an older GHC than I'd like. It's not cabal hell since its confined to one project and not system wide, but it's definitely a pain point.
"solver failed" is in theory a better error. it fails faster and is unambiguous. maybe because it's weird it is scarier? idk
the main issue is managing PVP bounds is a little hard to keep correct. but cabal also lets you "allow-newer" for duct tape.
Earlier quoted context omitted.
cabal hell isn't even a real thing anymore.....
I know that. Bumping GHC can still be relatively painful. Some language stacks are meaningfully easier on dependencies (not you Python), but can give you some other headaches (yes, you Python, damn you). Every PL in one way or another has some warts and ugly parts. It seems the job of a senior software engineer these days is to make fun of programming languages on HN pointing out their flaws, while simultaneously kee…
i could probably do my job and get passing (or better) perf reviews using nothing but fundamental-mode and the compiler.
& ultimately this is why Java/JVM keeps winning & to a lesser extent Typescript.
you benefit from the robustness of the JVM, compilation is fast, the language is fast enough.
to apply to Javascript/Typescript - good enough, fast enough though will not reach performance of JVM.
Earlier quoted context omitted.
Recently had to touch a Python project at work. Just setting up the editor needed me to use 2-3 tools out of: pyright, basedpyright, ruff, ty, mypy, and possibly other tools I'm forgetting that kind of do the same thing but throw errors in different parts of the codebase. Also, for some reason Optional[T] became deprecated, just as the ecosystem finally embraced types ~3 years ago. In fact, one my company's greenfiel…
I had a similar experience as you. We normally use Kotlin for everything, but last year we had to do a small project in Python. Setting up the tooling and choosing the tools is quite overwhelming, and the inconsistency between what the tools actually consider type errors is incredibly frustrating. I am actually happy that the project failed and that we don't have to work in that environment anymore. I think Python is…
Earlier quoted context omitted.
(Note: I work on Python tooling.) > for some reason we need 2-3 static analysis tools just for typechecking I don’t follow: you need one type checker, of which you have several options. It’s arguably not ideal to have more than one option, but you should never need to run more than one. - no tool understands each other's comment directives In general, all type checkers in Python support the `type: ignore` directive,…
If things were that simple... I have to use more than one Python type checker because there is not a single one that works. Not only different tools catch different issues. They also have different bugs, and different configuration requirements. Different teams have different preferences. It's a nightmare. If Python taught me something about typing is that a language that doesn't have a clear definition of types in t…
Earlier quoted context omitted.
"proving code correct has been a research topic at some point." It has been an area of active research for 40 years. But almost all the research returned the null result, meaning that the program proving didn't improve code quality (basically it didn't work). Yet somehow a group of programmers, usually fresh out of academia falls for program proving each generation. Strong types do really help but you need a good com…
That's literally the opposite of reality; the research and adoption have consistently produced code of extremely high quality, at great cost. The problem has always been: - It's extremely labour-intensive, and even small changes to the code can require an enormous amount of new proof work. - The skills required to formally verify software are very different from the skills required to write it, and the set of people…