5 ms·
It's not a bad thing to realize that one can be wrong and then strive for change.
by TheChaplain 4mo ago
It's not a bad thing to realize that one can be wrong and then strive for change.
- a-french-anon 4mo agoMaybe, but personally I've become quite tired of programming languages "organically grown" as opposed to properly designed the first time. After a good decade of C then C++, I found ANSI CL (despite being a massive compromise and unfinished) much more coherent and complete than both.
- ramon156 4mo agoSo which language had it right from the start? is there a language that has a very low rewrite status?
- bbkane 4mo agoI'd particularly like examples of statically typed languages that "got it right" (since I love me my types)
- galangalalgol 4mo agoOcaml maybe? Multi threading didn't seem necessary and introduced the possibility of data races.
- maccard 4mo agoThat’s whataboutism - no language is perfect, but given when go released it’s fair to hold them to a higher standard than languages what were designed 25 years earlier. As an aside - D, Zig, Rust, even typescript got most of the lessons learned from C right
- blanched 4mo agoI'm not familiar with D, but Zig and Rust are well-known for continuously evolving. Zig has the (in)famous "Writergate": https://github.com/ziglang/zig/pull/24329 https://github.com/ziglang/zig/pull/24329 And besides Rust's high count of RFCs, there are things like async (I'm not complaining about it, but its an obvious large-scale "change"), module system changes, etc. (To be clear, I like both languages a lot. But I wouldn't call them slow moving or right from the start.)
- Maxatar 4mo agoD literally can't even maintain backwards compatibility between minor version updates not to mention a big part of the D community left when D reinvented itself with D2. Among languages it's probably the one that is constantly in a state of flux.
- Kapendev 4mo agoReally? Wow, this is like Zig and I love Zig!
- sunsetSamurai 4mo agowhat's a big project built with D? I feel it gets mentioned a lot on hackernews but I've never run into any project using it in the wild.
- Kapendev 4mo agoFlutter
- sieabahlpark 4mo ago[dead]
- poncho_romero 4mo agoI think Elixir is a good candidate here. It's small, coherent, and composes well, and (at least to my understanding) the authors consider the language finished, with no new major features planned.
- sunsetSamurai 4mo agoElixir is missing static types though, it's hard to go back to work on dynamic languages.
- shakow 4mo agoHopefully, it's coming. https://elixir-lang.org/blog/2023/06/22/type-system-updates-research-dev/ https://elixir-lang.org/blog/2023/06/22/type-system-updates-...
- ndr 4mo ago"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." -- Greenspun's tenth rule He had some lack of conviction to scope it so narrowly.
- bbkane 4mo agoI know Go is justly criticized for many of its design decisions, but it still feels well-designed and "small" to me in day to day usage when many other languages don't.
- a-french-anon 4mo agoEh, the thing with generics coming late is pretty much what I meant by "organically grown". My best litmus test these days is support for multidimensional arrays because it's always needed at some point in general purpose languages. CL and Ada had it right from the start while C++ needed C++23/26 to get std::mdspan and we still need to wrap it to pass the underlying/owned memory pool around (https://rosettacode.org/wiki/Multi-dimensional_array https://rosettacode.org/wiki/Multi-dimensional_array for more).
- nish__ 4mo agoDoesn't every language support multidimensional arrays? It's just an array of arrays, no? What am I missing?
- School-Cotton 4mo agoAn array of arrays is an extremely inefficient and error-prone way to represent multidimensional arrays. If I want a 1000x1000 array, representing it physically as a single 1000000-element array requires one allocation, and processing it element-by-element (assuming it's stored in the same order we're iterating over it) is sequential in memory and therefore very efficient. Representing it as 1000 separate 1000-element arrays requires 1000 allocations, and pointer-chasing every time we move from one row to the next.
- nish__ 4mo agoI see. That makes sense.
- j_w 4mo agoIsn't an array of arrays by definition the sequential implementation? Otherwise you would have an array of pointers to arrays. The usage (syntax) for them would be the same but the performance would not be. They also have different uses. You would expect an array of arrays to be an array of arrays which share the same length. For an array of pointers to an array you would expect dynamic length arrays contained within the original array. Even in c++ could you not just define some int [1000][1000]foo? I've never really used C++ but my C knowledge assumption is that is 1000000 continuous elements.
- xscott 4mo agoScheme is (or at least was) coherent. You don't need to look any further than set/setf/setq to see that Common Lisp is "organically grown" from the fertilizer of a committee. CL does its best to make every other lisp more attractive.
- rootnod3 4mo agoWhich Scheme are we talking about? R5RS? R7RS-small? R6RS? With SRFIs? Without? Which scheme? Is it `(library...)` or `(define-module...)`?
- xscott 4mo agoHeh, I'd probably take R4RS with define-syntax :-)
- rootnod3 4mo agoI mean, good choice, but you see the point, right? As much as ANSI CL has it's flaws, it has a standard, as much of a mixed bag it might be. Scheme is just a general potpourri of "we kinda have a guideline, but do whatever". I would very much prefer scheme if the different implementations had a working standard. But I can't take my Chez-scheme code and throw it into Guile-scheme. But pretty good chance I can take my ECL code and throw it into SBCL or LispWorks.
- xscott 4mo ago> you see the point, right? Bah, I think this debate was already old when I first saw people arguing it on comp.lang.lisp in the 90s. I don't have a dog in this fight other than to reject the notion that Common Lisp is "coherent" and not "organically grown". The original Scheme belongs in the category of languages like Standard ML and SmallTalk, where a small, careful, and talented group designed them with focus. Common Lisp seems like a bunch of smart people with competing interest and legacy baselines tried to meet in the middle. To the extent CL is more pragmatic, it's another example of "Worse is Better".
- 4mo ago
- rootnod3 4mo agoANSI CL is such a breath of fresh air nowadays. Does what you need, doesn't get in your way, comes with batteries included. And conditions are just god-tier.
- shakow 4mo ago> comes with batteries included I like CL, but I can't agree that a stdlib that doesn't even have a string split function is batteries-included.
- nobleach 4mo agoAnd to bring it full-circle, this is the exact same thing I run into with Go. When I mention how nice it is that Lang X has feature Y, someone is quick to point out that either, "You can BUILD that in Go" or, "You don't really need feature Y". We've proven that we don't really NEED compilers either... but I would hate to have to do my job without them.
- boxed 4mo agoI liked Objective-C (except the C parts). Such a breath of fresh air coming from C++ which was grown like a cancer with tons of features and you felt trapped by every one of them. Objective-C in contrast was a very few additions thoughtfully added that composed cleanly and freed the programmer to actually get things done.
- iosjunkie 4mo ago"properly designed" - ah yes, programming languages are famous for universally agreed upon design philosophies.
- fhn 4mo agoso make your own and let's see how you do
- rootnod3 4mo agoHave you?
- chlorion 4mo agoI am actually working on my own language, and getting something better than Go is actually not that difficult! The hard part about making a language is creating the stdlib and tooling and support for the language, but actually creating a language itself that has more features and better features than go can be done by a single person in a few months or a year probably, depending on how much experience they have. Generics specifically are a great example here. A single person can implement a language with go-level generics fairly easily.
- ratrace 4mo ago[dead]
- pizza234 4mo agoIt isn't realistic to expect a design to be "proper in first place" because requirements change; my opinion is indeed the opposite - I find it natural for programming languages to have a (sort of) lifespan, and for new ones to (sort of) take their place.
- someone_19 4mo agoIndeed, in 2012, it was not clear to anyone that generics were needed /s
- array_key_first 4mo agoSure but literally everyone and their mom said these features were needed and then Go team said "nuh uh!!!" But, as it turns out, they are needed because they solve real problems, and are not just fake complexity like some people strawman. Hopefully next they can add some error handling syntax and controls.
- skywhopper 4mo agoYou may be tired of languages evolving over time, but there is no other way to build a rich and useful language.
- tux3 4mo agoI don't think anyone admitted any wrong or had any big change in philosophy. It's always a good thing to learn something along the way. But the current message seems to be that this was the plan all along, and it just took some time to design properly. Of course adding generics is not something that every language needs to do. Scripting languages like Ruby don't really need this style of generics. It doesn't fit the design of the language, and it's not even clear what that would look like in Ruby. But static typing with generics does solve a recurring problem, and we've seen some real convergence towards type hints and type systems even in staunchly dynamic scripting languages. Modern Javascript is now mostly Typescript, and they've successfully retrofitted a very advanced type system in the last place I would have expected 20 years ago.
- galangalalgol 4mo agoType hinting seems like the worst of both. You pay the cost on refactor to go change them all, where dynamic typing or static type inference avoid that. You also don't have any of the benefits of static or dynamic typing. My strong preference is static typing with good inference and an ide that shows the inferred types everywhere when asked. Dynamic typing can make some tasks dramatically easier, I'm just not capable of using them without making hideous mistakes.
- maccard 4mo agoThere’s a fine line between being willing to change your mind and getting the basics wrong. Go has repeatedly gotten the basics wrong.
- Jleagle 4mo agoSounds like you want this feature, and you just got it. Not sure how that's wrong. You don't add in every feature from the start.
- maccard 4mo agoI wanted it 10 years ago.
- whoiskevin 4mo agoDeclaring a highly successful language as having the basics wrong means that you are not correct about the basics that were needed.
- 9rx 4mo agoAn engineer, of course, understands that there is no such thing as "wrong", only different tradeoffs, but with the rise of "vibe coding" you don't need to be an engineer to play in the world of programming anymore.
- jeswin 4mo agoIt's a highly successful language because (1) it was backed by Google, and (2) created by Robert Griesemer, Rob Pike, and Ken Thompson. If it came out of anywhere else, it might have struggled even to hit the homepage here.
- amazingamazing 4mo agoThis logic is easily shown to not hold. Why isn't Carbon, Dart, etc. not really popular then?
- layer8 4mo agoIt’s still annoying ~20 years after Java did the same mistake of not including generics, which was already clear to many people with C++ experience back then.
- someone_19 4mo ago...and Java didn't even have basic enums or sum types from the beginning. But it had null. They added enums, they added sealed classes. They're trying to get rid of null (apparently it's really hard). The problem is that in 2012, when go 1.0 was released, this should have been obvious to everyone. Here's a famous discussion from 2009, three years before the 1.0 release (tldr: facepalm) https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY
- layer8 4mo agoI remember back in 1995 thinking that it was stupid for Java not to have generics, so instead you had to always cast Vector/Hashtable elements from Object, or implement your own type-specific container classes for every element type (and there wasn’t even a preprocessor to facilitate the latter). Sum types I didn’t really miss, because you can implement a type-safe equivalent using the Visitor pattern, and retain an interface-implementation separation that native sum types typically don’t provide.
- symaxian 4mo agoThat is an interesting read, seems some were having a hard time grasping the benefit of having compiler checks for potential null dereferences. Having worked with null safety in TypeScript and Kotlin the extra bit of strictness is nice.
- pjmlp 4mo agoThe biggest design issue with adding value types and non nullable to Java, is that the number one design requirement of any solution is not to break Maven Central. Every compiled JAR out there has to keep working as always on a JVM with updated semantics, and worse code has to be compatible, when passing class instances around between old and new code. Then there are the guest languages on the JVM as well.
- ivanjermakov 4mo agoWorst thing a programming language can do is introduce core semantics changes after 1.0. See Python 2 -> 3 and Zig's *gates.
- metaltyphoon 4mo agoExcept Zig is not 1.0
- ivanjermakov 4mo agoOf course, just a good case study of how radical languge changes are received by users.