4 ms·
If I were to make my own programming language, it would look an awful lot like Python. Roughly 100%.
by smitty1e 5mo ago
If I were to make my own programming language, it would look an awful lot like Python.
Roughly 100%.
- cornholio 5mo agoI agree, Python allows anyone to write bad code, but makes up for it by running the code slow enough that it can't do real damage.
- tzot 5mo ago> > If I were to make my own programming language, it would look an awful lot like Python. > I agree, Python allows anyone to write bad code, but makes up for it by running the code slow enough that it can't do real damage. In the same sentence you agree with the implied beauty of the syntax of Python and then go on sarcastically about the performance of CPython. Assumably you deliberately mixed language and implementation because you needed a soapbox, so hey, here's my comment to which you can reply and continue your rhetoric.
- cornholio 5mo agoIt's a joke. But you got it all wrong, it's not praise + sarcasm, it's double sarcasm.
- tzot 5mo agoYou say all wrong and then go on about explaining I'm half wrong. I feel there's a pattern (or maybe another joke that whooshed over my head) here but it is obvious to me that I am not your intended stand-up comedy audience and I should ask for my money back. :)
- wildzzz 5mo agoIf someone smarter than me didn't think to invent a new language to solve what is likely a common problem, the solution already exists.
- applfanboysbgon 5mo agoIt is absolutely not the case that all problems worth solving are solved already. Programming language development isn't necessarily about being a genius but rather a willingness to put in a monumental amount of work. Writing a language that compiles is easy enough. Getting a language off the ground to an actually useful place is tedious, simply in terms of the sheer amount of work to be done. Specification, implementation, documentation, diagnostics, optimization, configuration, tooling support, and creating a standard library (especially a cross-platform one) are things that will mire you in many hundreds of hours of work.
- imtringued 5mo agoThose are the easy parts actually. You're thinking of them in terms of time spent, which is not a bottleneck at all. That's an illusion. You need to be a genius, not in the sense of having a high IQ, but rather a genius in the sense of having great ideas. All your competitors are doing the ecosystem marathon, that's not a differentiating factor since your new language will always have a weaker ecosystem unless your language has concepts or features that negate the value of existing ecosystems. If you have a programming language that makes people 10% more productive, then people will have to spend 10x the time to use your language than it took you to develop it for it to break even. Increasing the amount of effort spent on the language moves the payoff further away. Your two key goals are developing a more effective technology and to convince people to use it. This means that differentiating features are critical here. Differentiating features are not present in the old ecosystem, which turns it into a burden rather than a benefit.
- Twey 5mo agoEven the _design_ of languages is a generational project. There are open problems in the PL space that we know need to be fixed but we have no idea how. Once you've got the ‘core ideas’ of the language in some papers somewhere (and proofs that they're coherent, which is usually the meat of the process) it's a pretty quick step to get a toy implementation, but then the path to an implementation that is usable for day-to-day work (especially if performance is important) can take decades, and the path to adoption after that can easily take between 5 and 20 more years. Then people figure out the thing about your core ideas that gets in the way when writing the kinds of real-world programs they want to write and you get to go back to the drawing board for the next language idea :) As an example of the kind of time scales involved, linear logic was introduced in 1987. Linear (well, affine) types made it into Rust 1.0 in 2015, which IMO is the first time substructural types have made it to a ‘mainstream’ (albeit still far from ubiquitous) language. And that's a very straightforward language feature that doesn't really challenge the dominant imperative/functional hybrid paradigm or have any inherent effect on performance (since it's ‘just’ a type system feature). IMHO the next big thing up (assuming LLMs and other AI advancements don't throw everything off-kilter) is probably effect systems, introduced in ~2013, for which we can linearly extrapolate a time frame of about 2041! But maybe not — one exciting thing that's been happening is that (as Jonathan Blow noted) with the growth of lower-level substrates like LLVM the work to go from a toy to a working and performant language has decreased significantly.
- cheschire 5mo agoYeah except my version would only accept tabs instead of allowing (and even encouraging!!) spaces for indentation.
- tzot 5mo agoI see that and I raise Elastic Tabstops! https://nick-gravgaard.com/elastic-tabstops/ https://nick-gravgaard.com/elastic-tabstops/
- Zecc 5mo agoElastic tabspots everywhere would be ideal. But in the real world I think 'tabs to indent, spaces to align' is the superior way, as every dumb text editor will support it.