I think the original statement was implicitly about using the language to build large complex systems in industry, not just about "using" the language which I agree would be kind of silly - who would work on a language they don't use in some way? But I always had the impression that most language designers were academics, e.g Alan Kay, Stroustrup, or professional programmers building what were initially 'hobby' languages (Ruby, python) rather than building something they would use in production in industry.
Standards must be low if that's now "deification" :)
His point is: while these things can be nice, no one cares about them other than language designer. They are only means to an end, which is user experience. Sure, some car buyers may know or care what alloy their cylinder block is made of, but a lot don't know, and don't care, how many cylinders there are. They only care (somewhat) about how it drives. And it is certainly possible to have a language with all the theoretically nice features, but offering horrible user experience for a specific purpose. Part of it is just marketing, but part of it is also optimization with a different purpose in mind.
For example, his purpose, and Julia's main use case, is often different from that of either a language designer or a software engineer: e.g. performance and fast prototyping are first order concerns (together with a decent scientific library), and everything else, like longevity, ability of future code reuse, or simplifying work of teams are way, way down the list. The reason of course is that ~90% of code is written by one person, for himself, to effectively run once and produce one paper, and to be never touched by anyone ever again. At least, this is what I see in my field, which is largely dominated by Matlab (and Matlab-like syntax is definitely a huge asset here).
You equate "teaching language" with "research language." You believe that a language with rigid syntax, static typing, and built-in OO would obscure the core ideas of computer science. Fine. You believe that. I'm sure you grasp that others, especially the list of people mentioned in the post, do not share your views.
So, what we have here is that you have certain beliefs about what makes a language suitable for teaching and what makes a language suitable for industry, and on the basis of your views, you do not believe that the same language would be suitable for both purposes. I accept logically that your conclusions are compatible with your beliefs.
I don't understand your last sentence. It seems to be some sort of axe grinding, as I certainly don't recall saying anything about industry programmers being ignorant or stupid.
So all together, I can't think of anything new to add to this thread. I feel like a foil used for you to set up and demolish your own arguments.
> Mainly because there doesn't seem to be an optimal language in any meaningful way. Communication seems to work fairly well regardless of language, so it doesn't seem like optimising the language itself really solves any meaningful societal problem. And if there's no clear advantage for one language over another, then people are going to stick with their own.
Why is this the case? The same certainly can't be said of, for example, markup and programming languages. C and Python express ideas in very different ways, such that you could not reasonably say that ideas can be communicated equally well in both languages, or that there's no clear advantage of one over the other in a given problem domain. There are indeed some programming languages that simply make it harder to program almost anything you'd want to write, like Cobol, Assembly, or Intercal. Is it really true that natural languages don't have analogous comparability in terms of ergonomics and expressiveness?
Not that you're saying it is, but it probably isn't ideal to use a programming language that is able to become mainstream. It seems likely that the ideal language should be (at least, at first) very difficult for an average mind to grasp. A language that inherently forces its users to be either 'naturally smart' or 'doggedly learned' will produce a better signal-noise ratio as a by-product: in open-source offerings, engineer-employees, and, at a micro level, within the engineer's code.
With that said, whenever readability is lost for the sake of ego, that is a loss. I'm not accusing the author of that though.
Sure, but the article is rather disparaging to the engineer spending their life in the so called ‘mainstream’ 99.5% of languages, implying their work is in someway less ‘smart’ than those exploring the 0.5%.
I am offering a counterpoint that instead, some ‘smart’ engineers have concluded that boring programming languages are the way to get big things done.
Nobody with any relevant industry experience would overstate the important of language design.
I've used many languages in my 25+ years in software development, and I've seen very little relation between language and either overall quality or simply getting stuff done.
I have however observed a strong negative relationship between that and people bitching about their and other people's tools.
No, because computer scientists are too lazy to create modern domain specific languages that are powerful enough for practitioners to put to effective use. :-)
> "Easier languages attract less skilled devs", "higher level languages allow you to create more complex programs", yada yada. Could all be true, but it's besides the point.
For the armchair discourse it's beside the point, but for real-world development, it's what matters the most.
Sure, many people do, and some don't. I suppose the point I'm trying to make is that decisions like that make one consider what are the assumptions and target audience of a project. In this case, as a potential user, if I'm looking for a language that's a deadly tool for doing difficult things, intentional limitations feel almost patronizing.
Most technologists don't seem to believe that design applies to programming languages at all. Programming languages are tools and tools are typically designed for efficiency, which is measurable - but you'll still hear things like 'syntax is personal'.
- It's worth optimizing for more people than fewer.
- There are a thousand times as many future programmers than there are existing ones.
- One can measure how easy it is for a clean-room human to read and create software in different languages and build something for them.
> I don't get why it seems like languages are designed for convenience then later down the road billions of hours are spent trying to get better performance.
It's easy to explain.
1. Most languages are designed for personal satisfaction of the author, not for commercial success. Perl, PHP, and Ruby were all just personal projects. Python was a language intended for education, then pivoted towards Perl's niche in the 90s.
2. The vast majority of languages that are designed will fail and be abandoned without anyone having ever heard of them.
3. Designing a pretty and elegant language is hard, but fun. You don't even need to implement it.
4. Designing a language that is deliberately amenable to optimization is also hard, but not fun (especially when optimization has to be prioritized over elegance). It's also hard to prove that your design actually yields good performance, which is hard and not fun. Furthermore, the only point of designing such a language is to hope to someday fully implement it, which is very hard and extremely not fun. And hoping to implement such a high-performance language in a cross-platform way is, for any single person, basically impossible.
The modern resurgence of high-performance languages like Rust is because, thanks to retargetable backends like LLVM, the idea of a hobbyist designing a new high-performance cross-platform language has gone from "basically impossible" to "unbelievably tedious though possible but also on some level your language has to basically pretend that it's still C". And also the consolidation of platforms for the past few decades now mean that there's fewer targets to support in the first place, and hence fewer C compilers than ever, so if you just want to transpile directly to C you can, though you'll still spend the rest of your life adding hacks to your compiler to work around bugs in every combination of platform/C compiler/C compiler version out there.
GP might work for a company working on a niche application (be it software or hardware) that requires code to be written like the aforementioned and anyone who specialises in that field is already adept in reading and writing code like that.
I'm not going to defend that choice of programming style for everywhere but software development is a broad industry where you do get pockets of people working on code that looks totally alien to others who are used to see C or ALGOL derived languages. Take LISP for example, there is LISP code in half of all European TVs shipped in the 90s. Forth is used in loads of places, even FreeBSD's bootloader is written in Forth. Machine code is almost completely unreadable for humans yet a massive chunk of software in the 80s was written using it.
My point is the industry might have standardised on a subset of syntax styles that seem readable to the lowest common denominator of developers but it's a massive industry with developers using all sorts of exotic languages effectively. Let's not go down the rabbit hole of saying they're doing it wrong because their code looks alien to you before you've understood the field in which that code is running in.
This reminds me of PG's essay on Java, in which he wrote "Java's designers were consciously designing a product for people not as smart as them.".
Ben says that smart people should also work with these languages because non-smart people might have to work with the code. I think that is actually what happens a lot in the industry. Smart people who know Lisp, Ruby, Python, etc. still end up coding in Java because that's the language everybody else knows.
What I don't like about this is that it's basically saying that people can't become good at programming. It's accepting that the majority of professional developpers can't learn to use languages like Lisp correctly or to understand a Lisp program that uses powerful abstractions.
Maybe the ones who really can't are not in the right business ?
It's not necessary for it to be a general purpose programming language, though. I think it is kind of neat to have a very specific, personal language that fits your mental model. On a larger team, probably not what you want, but there are other languages that are optimized for that.
Basically you're right if the creator wants a widely-adopted general-purpose language. But there's other valid approaches I think.
Nah, then it's pretty simple. My rebuttal is that I think "programming languages that programmers actually want to use"
(besides still being a debatable claim) is an insignificant metric. The industry doesn't pay for what you want to use.
"a manager counted the lines of software coming out of the cubicle farm and determined that programmers wrote N lines of code a day. It didn't make a difference what language was used -- the company would get only N lines out of them. The manager promptly embraced APL, the tersest, most powerful language around"
They can only do N lines, so the natural decision was to use terser languages, I love it.
I mean, yes there are reasons to use a special language for a problem (for example Elixir instead of Ruby, for distributed systems). Also sometimes some problems get solved more elegant in newer languages (Rust instead of C++ for system programming).
But if the only metric is lines of code, every language solves this with enough abstraction layers...
Sadly, many people don't. Try bringing up the idea of writing a large program in Ruby or Python and they'll balk at you saying that the languages are too slow. They will insist on using C++ or Java.
Standards must be low if that's now "deification" :)
reply