141–150 of 206 posts
It is the language, available tools and libraries, and the community. As a programming snob the fact that most of my coding is now done in Javascript is a threat to my identity managed with a handful of clearly reasoned explanations. This choice works with tools and libraries that support my needs and there are always more experienced programmers that can be called on when help is required.
It is the language, available tools and libraries, and the community. As a programming snob the fact that most of my coding is now done in Javascript is a threat to my identity managed with a handful of clearly reasoned explanations. This choice works with tools and libraries that support my needs and there are always more experienced programmers that can be called on when help is required.
I also avoided JS for no good reason until one day
Earlier quoted context omitted.
Why would management care about tools?
In the first example, they didn't and recruited a CTO who made a tool choice that arguably killed the business (maybe it still ends the same with PHP, minus the experience of building a nicely architected system in Perl: what-ifs all around). Management does need to care to ensure they hire people who will make the right choices (which is a careful balancing act of investment vs returns) if they don't trust themselve…
I dunno. I take the position that language designers have blind spots around the weaknesses of their languages. Python: Python is almost a hard-compiled language. Most of the dynamic stuff that's really hard to compile isn't all that useful. But Guido and his enablers love the dynamism, and the CPython implementation. So instead of PyPy taking over, we have CPython with hacks to call C. Go: The "share by communicatin…
Go: Greenthreading is a big deal in backends. Arguably the main reason for Kotlin is because Java didn't have that, but now there are vthreads. Rust has chipped away at the Go systems use cases, so it's mainly for backends and CLIs now, but I wish it had better error handling.
Rust: There's a very good preso from the Rust team about how they arrived at async/await, and also how every other language does concurrency. Greenthreading was considered, main problem being you need a runtime for that.
C++: Torvalds was right about it all along.
JS: Honestly the best high-level language, made better choices than Python, never made huge breaking changes, somehow had a decent answer to cooperative multitasking before most other langs, deserves its popularity.
Earlier quoted context omitted.
>Getting past paradigms gives you much greater freedom to explore and participate in the world. It's not me who has problems getting past paradigms, or anyone else I know for that matter, it's the recruiters and HR people who screen resumes by only ticking boxes on buzzword.
Engineers are also part of the problem, as not every engineer avoids myopia.
Earlier quoted context omitted.
"I cannot agree that programming language choice is a primary driver in a product's success or failure" I've seen it. There are definitely incorrect language choices for certain projects. It would be fair to say that these cases are themselves often exceptions. Many projects can be equally well accomplished by teams skilled in any language. But there is definitely a set of problems for which you can make incorrect la…
I’m having a hard time envisioning a project that could be killed by choosing Scala that wasn’t actually killed by bad engineering. Scala is pretty easy to write Just Simpler Java in….
Earlier quoted context omitted.
It CAN be. If a company chose brainfuck as a main programming language, it's doubtful they'd come back from that choice.
I think the assertion might even have been true for non-pathological cases 20 to 40 years ago. A company that chose Visual Basic or Perl would have had a much harder road than one which chose C# or Python. But i think the languages which have survived to the present day are all pretty close in productivity. Except C.
Based on what? Economics define where you go, not language. If company using Perl or VB has steady cash flow and their bottleneck is language - they’ll just rewrite when it makes sense. No amount of writing in C# or Python from scratch will save you if your product is garbage.
Earlier quoted context omitted.
> I cannot agree that programming language choice is a primary driver in a product's success or failure.... This and similar are common ideas for the people that never see the real whole world of programming, and maybe have the fortune of be in the "startup" circles. I see the opposite, and is very good predictor to know how bad a product or a team is, using the programming language AND the main DB engine, but that i…
If you are called in to rewrite the project, I would say this signals a successful project: it was built in whatever tech stack a midling engineering team had competency in, it originally worked well but started struggling with more scale/needs/updates, and it is still worth enough to invest in rewriting it. Yes, you may not enjoy turning a legacy system that works into a nicely architected system, but the ones that…
And because time to first release is often the difference between prosper and fail
It is not enough to be the best. You need to be the first
Earlier quoted context omitted.
I think the assertion might even have been true for non-pathological cases 20 to 40 years ago. A company that chose Visual Basic or Perl would have had a much harder road than one which chose C# or Python. But i think the languages which have survived to the present day are all pretty close in productivity. Except C.
I've worked for a company with a large code base in Visual Basic .net. Product been in development since the 90's, with rich customer that only cares about their software doing its job. It's a surprisingly productive language combined with Visual Studio. Even though, as a language enthusiast, I barfed a bit now and then. Dev team would like to switch to C# but it would have been a multi-year effort taking away from l…