| ▲ | a-french-anon 11 hours ago |
| Maybe, 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. |
|
| ▲ | bbkane 10 hours ago | parent | next [-] |
| I 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 8 hours ago | parent [-] | | Eh, 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 for more). | | |
| ▲ | nish__ 8 hours ago | parent [-] | | Doesn't every language support multidimensional arrays? It's just an array of arrays, no? What am I missing? | | |
| ▲ | umanwizard 7 hours ago | parent [-] | | An 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. | | |
| ▲ | j_w 5 hours ago | parent | next [-] | | Isn'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. | |
| ▲ | nish__ 6 hours ago | parent | prev [-] | | I see. That makes sense. |
|
|
|
|
|
| ▲ | xscott 10 hours ago | parent | prev | next [-] |
| Scheme 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 10 hours ago | parent | next [-] | | Which Scheme are we talking about? R5RS? R7RS-small? R6RS? With SRFIs? Without? Which scheme? Is it `(library...)` or `(define-module...)`? | | |
| ▲ | xscott 10 hours ago | parent [-] | | Heh, I'd probably take R4RS with define-syntax :-) | | |
| ▲ | rootnod3 6 hours ago | parent [-] | | I 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 an hour ago | parent [-] | | > 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". |
|
|
| |
| ▲ | rahen 9 hours ago | parent | prev [-] | | Scheme has a coherent and minimalist design, but its ecosystem and abstraction facilities feel too sparse for large applications. When I started building a Lisp-based machine learning framework, Guile seemed like the right choice because it provides GOOPS and generic functions, yet I still ended up with a lot of boilerplate to compensate for the lack of a strong type system. Scheme feels to me like C is to C++: not ergonomic for large-scale application development. Go is one of those languages that has both minimalism and productivity. |
|
|
| ▲ | ndr 10 hours ago | parent | prev | next [-] |
| "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. |
|
| ▲ | ramon156 10 hours ago | parent | prev | next [-] |
| So which language had it right from the start? is there a language that has a very low rewrite status? |
| |
| ▲ | poncho_romero 8 hours ago | parent | next [-] | | I 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. | |
| ▲ | bbkane 10 hours ago | parent | prev | next [-] | | I'd particularly like examples of statically typed languages that "got it right" (since I love me my types) | | |
| ▲ | galangalalgol 10 hours ago | parent [-] | | Ocaml maybe? Multi threading didn't seem necessary and introduced the possibility of data races. |
| |
| ▲ | maccard 10 hours ago | parent | prev [-] | | That’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 9 hours ago | parent | next [-] | | I'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 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 8 hours ago | parent | prev [-] | | D 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. |
|
|
|
| ▲ | rootnod3 10 hours ago | parent | prev | next [-] |
| ANSI 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. |
|
| ▲ | pizza234 8 hours ago | parent | prev | next [-] |
| It 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. |
| |
|
| ▲ | iosjunkie 9 hours ago | parent | prev | next [-] |
| "properly designed" - ah yes, programming languages are famous for universally agreed upon design philosophies. |
|
| ▲ | skywhopper 7 hours ago | parent | prev | next [-] |
| You may be tired of languages evolving over time, but there is no other way to build a rich and useful language. |
|
| ▲ | boxed 10 hours ago | parent | prev | next [-] |
| I 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. |
|
| ▲ | fhn 8 hours ago | parent | prev [-] |
| so make your own and let's see how you do |
| |
| ▲ | chlorion 5 hours ago | parent | next [-] | | I 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. | |
| ▲ | rootnod3 8 hours ago | parent | prev [-] | | Have you? |
|
