Are we Blub programmers? (2006)
weblog.raganwald.com
weblog.raganwald.com
i don't mind blub-tier java code (in fact, I dislike the parts of java where the API designers decided to get fancy, e.g. streams or I/O), it fits my brain pretty well so long as I am not dealing with teutonic AbtractThingDoerFactoryInjectionLookupService type code.
i prefer object oriented stuff and I dislike super complicated type systems. I even think java would be a lot cleaner if they had just said "generics are covariant like arrays, don't mess it up" and introduced function types, which captures most of the contravariant situations.
this is all blub-tier thinking, no serious computer scientist would advocate for this because it isn't logically sound, but it gives you 80 for 20 and is a lot easier to think about for my level of brain activity.
i am grug, hear me "hmmm"
Some of it does. The usage of two separate types for validated and unvalidated input entirely removes a class of bugs from the programmer, and enforces it at compile time, making:
string my_str = <some untrusted input>;
db.exec("select * from A where name='{0}'", my_str)
In any sane framework, that would be using prepared statements under the hood, so it shouldn't matter.
Python, one of the most dynamic of languages, is proudly including LiteralString in the upcoming 3.11 release:
https://peps.python.org/pep-0675/
I will say that yes, the Java ecosystem really abuses types due to the anemic type system that Java provides, but that's an indictment of Java, not type systems in general.
OK, got it, thanks! Should have gotten it earlier. Now it seems so clear :D
What makes you think so?
Creating new/any language isn't super-hard
Also no real-life product or business is built using a single PL.
When choosing a PL there are lots of other factors to take into account beside its level of abstraction and/or expressiveness.
I've worked on many "real-life" products where that was exactly the case. And plenty where the only second language was for the script for running the build.
I certainly agree choice of PL is only one of many factors that contribute towards success of a software company, but it's still an important one. Choosing a language that makes it impossible to find good devs who want to work for you is almost a guaranteed death sentence.
These days I worry about it less, primarily because C# let's you "go lower" when needed, and it feels like the concepts translate well enough. (But I still do plan on investing some time in both C and Rust... soon.)
C is very limited in how high-level it can go.
But on a more serious note, I really don’t think there is all that much outside C# in terms of features that is not in research phase - perhaps the borrow checker may be regarded as something that is no longer in that phase, but it has limited applicability, and is not needed for automatic memory management.
As for C, other than giving you some understanding of the fundamentals, it is a thoroughly unexciting language. I think it is only worth learning to get familiar with pointers, which is important.
When I'm checking interesting jobs then only C++ seems like other viable language for me
but on the other hand it's C++, painful environment.
Come for the libraries, the community, jobs, and productivity. Stay for the programming language.
It wasn't too long ago that PG said Python programmers were smarter.
Wanna do concurrent and parallel programming in a mostly seamless manner, not thinking about deadlocks and being isolated from most dumb mistakes that we all make? Go use Erlang/Elixir, Rust, Golang, OCaml 5.0 and a few others. You can't convince me -- or most practical programmers out there for that matter -- that you can use "most" programming languages "easily" for concurrent and parallel programming. That's bullshit coming from people who are either too idealistic or are stuck deep into their sunk cost fallacy aftermath.
Wanna do scientific number-crunching? I hate Python but I know its attached ecosystem excels at this. (Maybe Polars and a few other alternatives as well.)
Examples abound.
So as far as we can even accept the proposition that "Blub programmers" exist then yes I'd say most of us are kinda sorta "Blub programmers" indeed. It's inevitable; we have limited time and energy and on top of that our brain can burn out. I learned 8 languages and I haven't learned and used a new one ever since I learned Elixir and Rust 5-6 years ago. I am pretty sure I'll learn one or two more and that's going to be it.
It's normal. But it still doesn't justify the people who are like "Python everything!". Feels like they didn't even try to find the right tools for the separate jobs. Those people I can't respect.
None of them can prevent you from dumb mistakes regarding concurrency (maybe Erlang can do so by runtime checking). At most Rust and Erlang prevents data races (by the borrow checker and by not having shared memory, respectively). I don’t know much about Ocaml, didn’t it have quite a poor concurrency story? But I agree with you in that you can’t do concurrency easily (but I also exclude these languages)
> Wanna do concurrent and parallel programming in a mostly seamless manner, not thinking about deadlocks and being isolated from most dumb mistakes that we all make?
Neither of these languages allow for that, as deadlocks (and livelocks and all kinds of other race conditions) are not avoidable in any of them.
Rust and Elixir does prevent some race conditions (data races), Go does nothing (other than recommending the usage of channels, but that is still prone to race conditions), and I don’t know about OCaml enough to comment.
But if you are here to nitpick then congratulations, you have succeeded. :D
I don't like Golang but IMO it's still an improvement even though it doesn't save you from certain scenarios as you pointed out.
>Sky Broadband Shield
>weblog.raganwald.com has been blocked by Sky Broadband Shield, which lets you choose the websites that can be seen in your home.
>The site was blocked because it matched the following categories:
> Pornography and Adult
Backing out a level, it's not possible to look up a level of abstraction, because that view is basically every possible option, and an infinite space. You'd have to violate Gödel's incompleteness theorem to do so.
Most languages are Blub. Where we the programmers at large fail IMO is that we don't recognize that no language is universal. Some are good at X, others at Y, another group is only good for Z. But we all want to pretend that no no no, language A is perfect and you all are sheep for not seeing it and sticking to languages B, C and D.
So by extension, a single language with a huge ecosystem should suffice for any task.
For most purposes Python would also be more than 2x as productive than C, again given a developer with experience in both.
Elixir is not just 2x but very likely anywhere from 4x to 10x more productive. (I dislike PHP a lot but same can be said for it as well btw.) I got a REPL in which I can easily code 80%-100% of my workflow and test it in real time. After you recall REPL history a few times, copy paste in editor, run 1-2 more times to make sure it's still working and you're done (apart from unit tests).
I love Rust a lot and apply it more and more but I haven't had anything I ever finished in 10-ish minutes like I did with Elixir. I do love the guarantees it brings however and I am making an active effort to become fast and efficient (thus productive) with it.
Golang, as much as I dislike it in general -- because it doesn't go far enough with its static strong typing and people abuse its escape hatches way too much, effectively turning it into a dynamic language -- is a fairly productive language sitting somewhere between the above two. I am planning on partially replacing my shell script incantations with it.
And finally, shell scripting I've used and abused hundreds of times and my failure rate there is extremely low. There has almost never been any task requiring stitching different other programs that I didn't manage to do with it. And productivity is super high.
> in agreement with Brook’s famous paper
Meh. There is a good amount of timeless computer science writings but this saying isn't one of them. Some of the advice from older masters is simply outdated; they postulated things with certain assumptions and a good chunk of them no longer hold true (famous example is "storage is super slow" which is longer a given, you have NVMe SSDs that are like 10x-20x slower than RAM). Which is fine, I appreciate and cherish their contributions. But we shouldn't get stuck in our ways and should periodically re-evaluate our foundations.
> So by extension, a single language with a huge ecosystem should suffice for any task.
Yes, as long as the language itself enables productivity and as long as the ecosystem isn't a humongous collection of half-done and abandoned two-week passion projects. And as long as the language itself isn't a half-done mess that's never going to get fixed due to obsession with backwards incompatibility even though transpilers exist and a good amount of companies don't have ancient mastodons to support (hint hint, all of the above applies to Javascript / Node.JS).
IMO Golang and Rust do seem to satisfy your criteria. Maybe Java and C# as well (wouldn't know, I abandoned Java long ago). My favorite Elixir -- sadly less so because even though most of the common paths have been beaten / trodden, there are huge gaping holes at places. PHP and JS technically qualify although their ecosystems and the languages themselves are a huge mess. But I suppose "if you know what you're doing it's fine" (famous last words through which I made a lot of money fixing the messes of those "that know what they're doing").
More productive than what? Rust, Go or Shell?
And I already conceded in my comment that this is partially due to me still not living and breathing Rust. I'm quite good at it already but still haven't gotten to the point where my brain offers ready and baked idioms for a problem I'm currently solving.
Lisp's power is that you can always use reasonably efficiently it to write the blub you need to solve the problem. But if you already have a suitable enough blub at hand, that's not really helpful.
I’d think way, way harder about what database I used than which programming language. Most of them are just different stylings of C when you really get down to it. (Ok fine, not Rust.)
Your comment also crosses into internet psychological diagnosis ("PG’s problem is that he thinks [etc.]"), which is particularly sloppy and nasty. There's basically never enough information to justify this, since none of us has a mind reader.
You can make your substantive points without any of that, so please do that instead.
How do you tell what your language is missing? That's a real issue. If you ask people, they usually ask for incremental improvements.
Useful directions for work:
- Much of programming today is hooking thing A up to things B, C, and D. All have constraints. Are they properly satisfied? How do you tell? Secondary problem: If they don't quite connect, and you can't change them, can you bash them into connecting? Type theorists work on the first of those two issues, but usually ignore the second.
- Much software is plumbing plus algorithms. Classically, algorithms were the center of attention. But today, most of the algorithms are off the shelf, while each system has unique plumbing. Should languages be plumbing-first? Attempts in this direction (modules, APIs, CORBA, XML schemas, JSON schemas, REST, etc.) have usually assumed a master-slave relationship, where one side defines an interface and the other struggles to match it. Is a symmetrical approach possible?
- You can have all the CPUs you want, but they're not going to speed up much. We've been at 3-4 GHz for well over a decade now. Parallelism in languages has improved quite a bit, but it's improved from "it's not the language's problem" to "we have some reasonable primitives now". Not to "as easy as sequential".
- Why does the complexity of web pages seem to grow without bound, despite them not doing all that much more?
- When it really, really needs to work right, software isn't that good. Even for small programs. Consider Solidity and the track record of smart contract hacks.
- Some things don't need to be Turing-complete. We don't have good ways to make them. Older technologies, such as ladder diagrams, decision tables, and simple regular expressions, have fallen out of favor. Some of those are exhaustively testable, which is useful.
Mostly correct but there are exceptions: Erlang/Elixir and Golang in particular make concurrent and parallel code extremely easy to write and 99% of what can go wrong is already taken care of for you. Rust makes pretty good strides as well, and OCaml 5.0, once stabilized, promises to give you an ML language with GC memory management and very good parallel primitives that its community will likely quickly develop further.
It's super strange to me that most programmers actually refuse to acknowledge that there is such a thing as the right tool for the job (not talking about you, you obviously are more open-minded, judging by your comment). That seems to be the bane of the modern programming -- the people and their bias. A lot of us became wannabe council of elders.
And I completely agree that non-Turing-complete technologies are extremely useful. I've been preaching for a configuration language that deliberately omits several important things (like passing functions around or recursion) so you can never hack a system through a malicious config. Alas it seems nobody cares until I sit down and write it...
> - Why does the complexity of web pages seem to grow without bound, despite them not doing all that much more?
Sigh. I'd like to know as well. Likely the newer generation are a bit spoiled and feel they can pile complexity on top of other complexity forever? Or, much more likely, nobody sticks around for a long time in their workplace and they are like "frak that, the next guy is gonna fix it"? Who knows. But it's indeed severely not okay.
The extent to which this false evaluation context is unfair is belied by your need to ignore the actual evaluation context. His essays were written in part to help him think through problems related to starting companies, because he founded and popularized startup incubators. The startup incubator wasn't just successful, it was successful to the point of broad influence. Others have since copied his approach.
Now putting aside that the comparison is ridiculous: your guess as to what he would get in grades is probably also wrong: How to Disagree is an example of an essay that would do very well in a Critical Thinking course; actually some people who teach Critical Thinking suggest people ought to read it.