Most beautiful languages?

In your opinion what are some of the most beautiful languages? Do you know why you find them beautiful or do you just vibe? (It doesn’t need to be only with regard to syntax) >Elixir Pattern matching and the pipe operator are nice. The way the actor model solves concurrency and reliability very elegantly without the brittleness of some type systems. The ruby syntax. It’s just a nice language. Some other languages I think are beautiful are Ruby and Elm. Don’t turn this into a flame war. If don’t like someone else’s language either ignore them or suggest another language that you think would fit their tastes.

I'll say it; perl. perl 5 real mans perl. simple man think is kinda elegant its fun to write- cpan is pretty easy to operate- and idk I like it i also like ruby and feel like it's been interesting to get into it a little

>>30365 The regex support is considered a strong point, isn’t it?

>>30364 Lisp(Common, Scheme and Racket). I hardly use them but I love to look at those source codes written in any of these 3 languages. I have no idea why I love it, but may be because of (((((()))))).

While it's possible to write ugly Lua, I find the syntax and the simplicity of the language beautiful. Switching back to other languages I often find myself missing Lua's elegance.

Nothing comes close to (Common) Lisp once you have dedicated a few hours of effort to get over your parens babby duck syndrome; you also need to learn the jargon (car/cdr, nconc, *p, loop, setf, etc...) and know the standard macros/special operators to know which parameters are evaluated, but that's no more effort than other "different" languages. Can't ignore your disgust of symbol soups (e.g. ruby/elixir, perl, rust, haskell, etc...) once you've seen the light.

>>30371 I mean, sure, but it's not conducive toward collaborative making It doesn't fit the thread, but I think beauty in a programming language must include the actual accomplishments in said language. Otherwise we may as well talk about the best onahole models Yes, Common Lisp had a great run back in the 90s; where is it now? From my survey over the past three months, hard to say. People come out of the woodwork and say "B-b-but look HERE! It's being used in QUANTUM work you FRICKEN idiot" And sure, but I'm a dunce inhabiting reality. one has to learn a custom DSL for every common lisp project, doesn't sound great The simplicity in knowing a set of symbols is more than enough Why don't people actually want to make stuff anymore? Despite my love for Lisp and other interpreted languages, I must kneel to C++ and C lads

>>30372 >Yes, Common Lisp had a great run back in the 90s; where is it now? The standard is intentionally frozen, so everything is compatible. Yet, you can extend the language via macros and libraries. >Despite my love for Lisp and other interpreted languages, >Lisp >interpreted You are a C programmer if you think that Lisp is only interpreted. In fact, most Lisps are compiled nowadays.

>>30372 Why do you care if a PL is popular or not, as long as it has good enough libraries to speak with the outside world (e.g. JSON/XML or various DBs)? Are you the kind of guy who listen to radio music, or what?

>>30374 If you're writing a large project that somebody else will eventually have to maintain, it is wise to use a language that a large amount of people understand.

>>30373 Lisp is both interpreted and compiled, yes. I recall seeing some benchmarks where it was faster than C or something. That's great. >Yet, you can extend the language via macros and libraries. And I agree with that too. There are good libraries out there and there isn't a constant hamster wheel of updates you have to keep up with. But, again, these are both just properties: the failure here is the proverbial wheel that haunts all programming discussion. >>30374 >Why do you care? If someone wants to spend their time on these things, all more to them. What saddens me the most is the stasis that virtual reality maintains. There were programmers here twenty years before us, and there'll be programmers twenty years after us. For many years we have been reinventing wheels. For many more years we will continue to do so, and then parade the achievement because we made it faster or more clean or some other thing. HERE is my frustration: people laud programming languages or the new services, but rarely anything is DONE. We will FLAME here for the next 50 years, reinventing the same stuff across 50 different libraries, and NOTHING was accomplished at all! People want to swallow up the latest technologies, posit the beauty in an s-expression; and that's all fine and dandy if we're in some college campus. But I look outside and we are dying. We are dead. There is nothing. My frustration is this: all of this is a distraction at best. That is why I kneel to C++ and C lads, for they've at least built our virtual prison. https://youtu.be/nUsDk8wjRPs I'LL YELL OUT TO ALL OF YOU WHAT ARE YOU GOING TO DO WITH YOUR FAVORITE LANGUAGE OTHER THAN PROGRAM A DILDO? TELL ME OF THE LIVES OF ALL OF THOSE PROGRAMMING GIANTS, WHAT ARE THEY UP TO NOW? YOU TELL ME TO LOOK AT LET OVER LAMBDA, WHERE IS ITS AUTHOR? YOU TELL ME TO READ SICP – TELL ME, WHAT HAPPENED TO THE AUTHORS THERE TOO? And before you ask me, I know very well I am a dunce. I know very well all I can do is program dildos. I know the very best thing I can do is be swallowed up, fashion together some harvesting device in a form of an online service, and that's all that's left as resource. All that's left in the advantage of programming. You are the bird who has come to love its cage. I hope you are able to install platinum for guard rails this upcoming patch; bronze is so out of fashion.

>>30371 I think lisp is very elegant: lists, atoms and how to compose them. From that you build everything. But I just haven’t found and implementation that is also pleasing to the eye. Scheme comes closer than CL but it’s not there yet. Maybe Julia will do it, if you want to consider it a lisp. But I would prefer if it were more general purpose.

>>30376 "Reinventing wheels" is how things get done. A bicycle wheel is different to a car wheel and those are different to carriage wheels. Making things (relatively) from scratch, to learn how things work, what the trade-offs are, and to see anew with eyes unclouded. However people are reinventing cages, not wheels, as you say. Programming is a new thing to modern humanity, understanding & capability is very limited. Institutions present programming as a solved discipline, with "wise experts" that have figured everything out and already made all the mistakes & learned them for you. So people are afraid of doing something different, or the thought never even comes to mind. Progress has gone backwards as people are trying to duplicate other's claimed past successes instead of exploring and understanding.

Nothing more beautiful than LISP. When I first learned LISP, I dreamt about LISP code for a few nights.

Sorry I posted too soon... I don't know which language I should pick for writing small programs and scripts. I would like to learn Tcl but the community is too small, I think. Other choices include languages like Perl, Python and Ruby. The problem with Lua and C is that the standard library isn't big enough. I'm kind of interested in NewLisp and picolisp (but they have too small communities). Racket is interesting as well. C is not a good choice because I'm not writing a kernel or software for embedded systems. C++ is too complex for my taste. And Go seems to be overkill (just like C/C++ or C#/Java). I heard the situation with Python's package managers is quite bad: there are like 2 or 3 package managers and all of them suck. On the other hand, Python has great docs (like Racket and Perl). Perl, Racket and Ruby have better package managers. I like that there are optional type declarations in Racket and Python. Python and Ruby both have large communities, and Perl has PerlMonks. Tcl has the wiki. But do these other languages have places where the community usually hangs out? Python is the most often recommended scripting language. But I would like to hear why exactly (since both Ruby and Racket are quite easy to learn as well). Python's global interpreter lock is also quite bad for the performance.

>>31430 Python's power is in adoption. It has a huge number of libraries for literally anything and a simple package manager. Python has its flaws as a language but I do love it as a language with which to get things done very simply. For example Python has such little mental overhead that whilst waiting in queue for a game of Overwatch (forgive my game choices) which takes around 4 minutes I was able to hack together a script to check the beta signups every minute and make a sound when it launched. It took around 10 lines of super high level and clear code, where as I'd hate to imagine the Perl version in terms of writing speed and clarity. Another example of its universality is that I used it to create a script that would hold the shift key down for me when playing VRChat since it lacked toggle sprint. Good luck doing the same in perl (I haven't ever touched Tcl though I imagine it would struggle too). Python just has so many extremely abstract libraries that you can do whatever you want with it. Python is used for everything from automatically downloading porn to performing data science and running machine learning models. Perl would struggle to do even half of what Python does daily. I used it to optimise boolean logic a few days ago in fact. It's all good being hipster and lightweight at times (I like a good suckless program myself), but sometimes you just want to get something done in a hacky way in 10 minutes, which Python can do for you no matter the problem and with little thought. Yes it's a normal person language, but sometimes even normal people are correct.

>>31430 >Other choices include languages like Perl, Python and Ruby We don't know what really matters to you, so can't really advise you. Personally, I chose Tcl at a point in my life where I only knew C, all the UNIX DSLs (make, sh, m4, awk) and a bit of Python. Python worked fine, but I disliked a lot its lack of raw power (cf Lisp macros or Tcl uplevel), its too big core, the GIL, its (Guido's) attitude toward FP and general "jack of all trades, master of none" reality; its only advantage is that it's "alive" and, as you said, with a big community. I attached a text file describing what I think are the main attractive points of Tcl.

>>31430 I think you should go with Tcl, because you show genuine interest in it. I don't know why exactly you find its size a problem, but you could put that to the test. For example. if you fear there'll be a shortage of information, you could search for "tcl" plus the three or four problems you've most recently struggled with, and see if you would have found an answer if you had been using Tcl at the time. Adapt this to your actual concerns; maybe you will decide it best to leave Tcl for later after all, but you should give yourself a chance first. As for your question, my impression is that Python is most commonly recommended for two reasons: it's the most popular, and it sticks to the paradigm that's familiar to most people. The latter is clearly irrelevant for you, since you're considering Tcl and Racket; as for popularity, again, you'll have to decide why it matters to you and how much of it you need. It sounds like community interaction is what you have in mind? Finally, since you mention type declarations as a good thing, I think this point deserves elaborating upon: Python indeed supports type declarations as documentation, with some third-party tools being able to perform type-checking on them. Racket supports several languages out of the box, and one of them is a native statically-typed language with algebraic data types - a wholly different league. Perl also supports static typing natively, but I know no details on that.

>>30364 Nim is the cleanest lang i've ever used. Enjoy elixir, and think it's the best dynamically typed lang, but it has too much Ruby-isms for me, and apparently they want to try again with some form of static type system.

I find Ada to be one of the cleanest languages at the logical level. The type system just makes sense. The code is readable even if you do not know much of Ada, and I include advance programs here. It is a language that is just requires you to write down your problem in a fairly human way and then just solve it like you would in your head. Here is a quick snippet I created just to show the basics of the type system and some syntax. with Ada.Text_IO; use Ada.Text_IO; procedure Beautiful_Ada is -- Spanish grades go from 0 to 10 type Spa_Grade_Coarse is range 0..10; -- But what if we want decimal precision? type Spa_Grade is delta 0.01 range 0.0..10.0; -- This is not a float, but a fixed point type! -- We also have decimal types, but that is for another time -- And yes, 5 and 5.0 are different types! subtype Spa_Pass is Spa_Grade range 5.0..10.0; -- One needs a five or greater to pass -- Lets define some data to show off type Class_Grades is array (Positive range 1..<>) of Spa_Grade; -- At least one student! Some_Grades : Class_Grades := (1.01, 0.0, 10.0, 7.99, 5.3, 4.99); begin for I in Some_Grades'Range loop -- Never use explicit loops if Some_Grades(I) in Spa_Pass then -- Test condition on the type! Put_Line("Student" & I'Image & " passed with grade" & Some_Grades(I)'Image); -- No need to add trailing spaces end if; end loop; end Beautiful_Ada; And once again, this is just the type system. Tasks are also quite easy to get. So are contracts in Ada/SPARK, which I think it is the most readable "provable" language out there by a mile. Also, one neat mental exercise would be "How would I rewrite this lainanon's code in X programming language?". I think most people turn down Ada because they see the code and think "well, that is basic and simple" but then they are not aware of the abstractions they have to go to achive the same thing in other programming lanuages. It would be trivial to change this code to allow for the French numeric grading system. And it would also be simple to implement the German/Austria/Swiss one. The American system would be even simpler. And we can do all that with the type system. No need for templates, macros or objects. And we get checks for free! I also personally like Scheme and Lua for how small they are and how much they can do with so little.

>>31587 I really hate that x'y notation in ada. It just rubs me the wrong way using a single quote for that.

Faust (https://faustdoc.grame.fr/manual/syntax/) is a rare example of a beautiful domain-specific language. it's meant for writing audio processing algorithms and uses a haskell-like functional syntax. my favorite feature is the composition operators, which roughly stand for ring buffers or pipes, but allow you to effortlessly split, combine, stack, and mix audio channels. typically these sorts of high level audio programming tasks are handled with visual graph/node based editors (Max/MSP and PureData are the most popular in the music production world) but i have found faust to be even easier than to use than a visual editor. >>30370 i like lua because its like python if python didnt try to hide what its actually doing from you. "everything is a dict" dynamic languages have a certain elegance to them but too often they pretend to be java.

>>31590 >pretend to be Java Elaborate on that if you would

>>30375 if you write it that language becomes a popular language because people have to learn it to maintain your code. also fuarrrk other people do what's easy for you. also if we followed your logic we would all be using Fortran because it was the first language, and therefore everyone should have used it.

>>31588 It's reasonable though, maybe not the best choice, but that is really just an actually unimportant detail. Consider for example the often recurring syntax structure in the form of value = values['key'] , what's so different about it compared to something more ada like values'key ? I'm not sure I would pick ada for elegance though, it's often quite verbose. This is coming from my perspective as someone working with VHDL, which is only a domain specific adaptation of ada, but I'm not sure whether ada is even practically used for anything else.

>>31609 >what's so different about it It's just a really unusual choice of character to use. I can't think of any other language that would consider a quote for anything other than quoting, let alone it being a binary operator. I get that technically there's no reason why any particular character needs a certain purpose, but as I said, it rubs me the wrong way whenever I see it.

>>31609 Not the previous anon, I find it jarring too. You're comparing a case where it's pure syntax and the content is what's inside the quotes with an operator where you really want to see it. My big problem with it is that it's not easily noticed; though syntax highlighting does "fix" it, and I'm sure you get used to it.

>>31587 ADA is really interesting. Definitely in my to learn list.

In terms of elegance, Haskell takes the cake. Writing a Haskell program forces you to really think about what you're doing in terms of abstract computation, so I find that when I write code in it that code is very clean and elegant and my comments are useful (because I had to think about how it works) For that same reason Haskell is impractical for a lot of tasks and I don't write it much.

I hate to be that guy but: C, standard 1989. It has just the right ratio of keywords/idents. It has just the right level of abstraction. Enforcing declarations at the beginning of blocks helps understanding the code, it makes the compiler simpler, it's a logical implication of the data/code separation paradigm. It just looks good, without any weird symbols or syntax.

>>31717 Just lacking real macros to be able to go beyond when needed. But macros without homoiconicity? I don't know. C99 feature list from Wiki: >inline functions Useful, please keep them. >intermingled declarations and code: variable declaration is no longer restricted to file scope or the start of a compound statement (block), facilitating static single assignment form I'm sorry, but limiting variable scope can be really useful. >several new data types, including long long int, optional extended integer types, an explicit boolean data type, and a complex type to represent complex numbers >new headers, such as <stdbool.h>, <complex.h>, <tgmath.h>, and <inttypes.h> Certainly, useful, no? And let's be honest, variable width types were a mistake. >variable-length arrays (although subsequently relegated in C11 to a conditional feature that implementations are not required to support) No, please. >flexible array members Quite disgusting. >support for one-line comments beginning with //, as in BCPL, C++ and Java Can do without. >new library functions, such as snprintf Thank god. >improved support for IEEE floating point You don't want this? Really? >designated initializers (for example, initializing a structure by field names: struct point p = { .x = 1, .y = 2 };) Very nice for readability. >compound literals (for instance, it is possible to construct structures in function calls: function((struct x) {1, 2})) I use it, but I'd understand if people found them confusing. >support for variadic macros (macros with a variable number of arguments) Not being able to wrap printf in macros was painful. >restrict qualification allows more aggressive code optimization, removing compile-time array access advantages previously held by FORTRAN over ANSI C Keep it, obviously. >universal character names, which allows user variables to contain other characters than the standard character set Botched by being impl. defined.

Algol-60 did block structure the right way, and it's actually generally pretty "human-readable."

>>31754 Algol's interesting in that it was designed for computing rather than computers. The main goal was to be a notation for algorithms, hence the name. It gives it a much more "mathy" feel than most modern programming languages.

I'm surprised APL hasn't been mentioned yet. It's a very concise language created before character set standardization destroyed the ability to express programs with specialized notation. This notation is its primary draw, which later derivative languages abandoned, and I can often remember the primitive I wish to use by merely looking at the keyboard. Equally important is its intense focus on many-operations-at-a-time computing. Loops are avoided by reshaping data so that the language primitives properly process everything, conceptually at the same time. It has a thread here: >>24803 >>30376 Idiots get lucky. Good doesn't always win. I agree we shouldn't program with languages at all, but very specialized tools. >>31587 I don't believe a range 1..<> is permissible. A range must specify both ends or neither end. Regardless, I also like Ada; it has more powerful arrays than APL, since they can be indexed by any range of a discrete type. I'm proud of the Ada programs I write, and the pride is similar to my pride in the APL programs I write. They're both beautiful languages. For a similarity, both Ada and APL only feature line comments. It has a thread here: >>11673 >>31717 >It has just the right level of abstraction. Oh yes, the C language programmer balks at using an assembler; what a waste of time. He balks just long enough to stop at the C language; writing in a language that doesn't require that drudgery is just silly. There should never be an end to the abstraction at which one programs. >Enforcing declarations at the beginning of blocks helps understanding the code, it makes the compiler simpler, it's a logical implication of the data/code separation paradigm. Look at how Ada does it, with a distinction between blocks and blocks which declare variables. >It just looks good, without any weird symbols or syntax. Its comment syntax interferes with its other syntax. Its ternary operator is bizarre. It's responsible for confusion about the basic concept of a pointer. Does this look good: http://pigeonsnest.co.uk/stuff/pigeons-device.html

I like prolog because every statement has a logical declarative meaning. Writing a prolog program feels much more like writing a proof than other languages I have used.

>>31614 J uses the " character as a unary and binary operator.

>>31767 Sometimes you need to deal with the minutia to make your program run very quickly. That being said it is usually better to have an abstract language because the higher level of performance you can get with less abstraction isn't really worth the time. I have not used APL but I have used J (which is basically like ASCII APL with more features). J is nice to write but not to read. The main reason I think this is is that the language is too dense. It contains too much information in too little space. Looking at APL, It seems like J in terms of information density. For something to be easily readable, It needs to have the right density. I don't really have any qualms about using APL, but when I consider the beauty of a programming language readability is a chief concern.

Scala and Clojure and Lua Perl obvs

>>31772 Yeah, but they ran out of characters to use for things. Also the point here is about common usage. Last time I tried I couldn't even download a J interpreter on my machine; it isn't exactly commonly used.

>>31772 When you use J/APL for syntax justification, you know you have problems.

>>31717 I want to like C, but whenever I actually sit down and start using it, I end up thinking "I wish I had x feature right now". A lot of time is wasted implementing basic things other languages do for you.

>>31874 >The only reason people like or care about programming is because it allows them to use logic to do soykaf. More generally, they're forced to care by the modern world. >Liking the actual 'act' of programming instead of the finished goal is like being an enthusiast of paint instead of the idea you'll realize to fruition with the paint. >Go ahead. Tell me something I wouldn't know. That's fair but, as a passionate enthusiast, I've realized the overwhelming majority of programming work is worse than useless. I don't hack around every day, and often the proper way to program is to metaprogram instead. There should be less software, never more, and it should be correct, more hardened, more documented, more abstract, and more useful. >When it comes down to it no one will truly care at all what you use, as long as it's a somewhat popular language with a robust toolchain and libraries. When it comes down to it no one truly cares about that either. What others actually want is to automate work. Bad languages make work. >The only reason people tell you to learn C is so that you can appreciate how much easier other language's syntaxes are. No, it's because they're ignorant and deluded into believing it to be some inherent and pristine fact of computing. It's a retardant for computing.

Rust, Perl, maybe AWK but i haven't looked too much into it, and any Lisp

>>31885 >There should be less software, never more, and it should be correct, more hardened, more documented, more abstract, and more useful. It would be nice, wouldn't it? Instead we get blockchain web 3.0 cloud data workflow solution apps

>>32037 Rust, perk and awk are beautiful? Ok, interesting opinion. I can totally agree that lisps have a beauty to them. >>32041 Forgot about AI, machine learning and data science.

>>32057 Ok I don't really think Rust's and AWK's syntax is beautiful but they're just neat. And Perl's terseness is kinda beautiful to me.

>>32067 Rust and AWK can be very useful, yes, I can’t disagree with that.

>>30364 Easy: R7RS Scheme and Lisp some of the time. I don't need to explain myself, it's math++.

F# Once I got wise to dotnet's telemmetry though, I haven't been able to bring myself back to it. Bros, I miss it so bad. I've dabbled in Racket and Elixir, but I haven't hit a stride where I am productive. Nowadays I just use Python for everything because the the effort to get a minimally viable product is low and its always good enough for what I do.

>>32175 So you like F#, but its only available implementation is unethical. That sounds like a job for a programmer, doesn't it?

>>32200 I have 2 kids, one on the way, and work about 50 hours a week. There’s no way I can reimplement F# and key libraries in anything like a reasonable amount of time. It would also just be worse

>>32175 >F# What aspects of F# do you like? Maybe someone can recommend language you'll like that isn't problematic for you.

>>32204 >I have 2 kids, one on the way Imageboards really aren't what they used to be.

>>32175 Isn't .NET open source now? Or you could just use Mono.

>>32206 Some of us grew up, got a job and still come back once in a while. The most dysfunctional posters cast a pretty big shadow that may make 'image board people' seem weirder than they are. >>32207 Yes, .NET core is open source. It is a Microsoft product, like Go is for Google, and Java is for Oracle. That I have the option to inspect the source or offer a patch is nice, but my problem with .NET core is that I can't even open FSI without MSFT hoovering up a bunch of my information. I mean, damn, you really need to fingerprint my system for ". . . y'know . . . reasons . . ." before I can even add a couple numbers? Yes, you can set some environment variables and pass options to dotnet every time to avoid this, but you shouldn't have to. At best, it shows total contempt for users. That the information is used for some kind of evil is an admittedly paranoid position, but it's certainly not out of character. All that said, F# is nice _despite_ being a .NET product. Once the silliness of the VM and that whole C# way of doing things rears its head, the fun ends pretty quickly. >>32205 I like a functional approach. I really appreciate that the effortless types make a domain-modeling-first methodology a good default choice. Pipelining is also very nice because it lets you express code in a left-to-right fashion. A Scheme or Lisp would scratch most of those itches, but writing code from the outside in [ (do-this-last (do-this-next (do-this-first())) ] slows my dinosaur brain down. Elixir seems good, but I haven't used enough to 'get it' yet. I know F# is just OCAML on .NET, but my expectation is that anytime you need anything outside of the basics, you're on your own. Basically everything I write are small-scope, single purpose applications to solve specific engineering (roads, not software) problems, analyze data, and automate business-related tasks. I know Python is the 'right' choice for that, and I use it constantly. Every time I write Python I am reminded of its incredible goofiness and that "Worse is Better" was a prophecy, not satire.

>>32208 > Scheme or Lisp would scratch most of those itches, but writing code from the outside in [ (do-this-last (do-this-next (do-this-first())) ] slows my dinosaur brain down https://github.com/hipeta/arrow-macros/ Can even be :use'd without any fear of symbol collision.

>>32208 >writing code from the outside in Having editing macros helps a lot with this. I have a lot of binds for lisp editing, but I consistently find the most useful are Space-[iIwW] which will wrap the current list/atom in brackets, and put you in insert mode at the start or end of it. Also Space-[hl] to jump to the start/end of a list in insert mode. There are a lot more but those seem like the most used. It basically means you can write the code in the pipeline order you think of it, but the text ends up in the right order for a lisp program.

>>32211 I'm pretty sure he includes "reading" in the inconvenients, too.

>>32210 Is it really that easy? Seems like that would be baked in. Worth a try, though.

>>32214 It is builtin in Clojure, where it comes from (I think?). Way to old for the '93 CL standard, and as we can see, doesn't need to be in it. I do have (ql:quickload :arrow-macros :silent t) (import '(arrow-macros:-<> arrow-macros:-<>>)) in my .sbclrc

>>32215 Yes, Clojure is a nice language. Rich Hickey seems to have consistently good judgement. I usually develop on Linux and sometimes deploy to Windows, so I did miss the simplicity of Go for that task. I still don’t actually know how to make a Clojure program run somewhere you don’t have root. I might have been screwing up JPackage. Out of curiosity, what kind of programs do you write with Common Lisp?

>>32216 For now, none, I'm too beat by depression and the months long heat wave without AC (renting a flat in the south of france, where eco-tools are running amok making retarded laws). But I plan on writing a ranger replacement using McCLIM once I get enough energy, so that I can get nice xattr support and proper asynchronous FS metadata fetching. Personally, I superficially dislike Clojure (how it looks, lack of reader macro, JVM jank, no CLOS) when compared to CL.

typescript is beautiful and relaxing for me

>>32238 > In France > A baguette-throw from Inria > Not using OCAML > Not using Coq bruh...

>>32251 Did enough OCaml in school, already. Lisp > ML if you have any aesthetic sense (or just eyes, especially in the case of OCaml). PS: CL has ADT since you can use "and" and "or" in type specifiers and match with the awesome trivia macro

>>32251 Iniria was influencal in lisp and CL in particular. They made le-lisp and a foundational lisp that made its way into the maclisp lineage. And le-lisp was the original language ocaml compiled to iirc

>>32257 With the https://github.com/ruricolist/serapeum you can even get expansion time exhaustion checking over those types. Note it doesn't like nots for exhaustion I've found

>>30371 Lisp is cool, but it's a bit too pure for me. If you've seen one line of Lisp code you've basically seen em all. Whenever I read back other people's Lisp code my eyes glaze over. It feels like I'm reading XML.

>>32270 You basically are. XML is a self-describing tree. S-expressions are a self-describing tree.

>>32270 You just haven't yet merged into the REPL, that's all.

>>32257 OCaml and SML are beautiful. Just avoid the O in OCaml and you'll be good :)

>>32270 This sounds so off to me, considering I still find Lisp code that looks new to me. My editor turns luminosity of parens really low, so its like writing hy with good parenedit.

>>30376 >people laud programming languages or the new services, but rarely anything is DONE "In the 1990s I followed the Usenet group comp.lang.forth. Forth has great personal appeal. It's minimalist to the point of being subversive, and Forth literature once crackled with rightness. Slowly, not in a grand epiphany, I realized that there was something missing from the discussions in that group. There was talk of tiny Forths, of redesigning control structures, of ways of getting by with fewer features, and of course endless philosophical debates, but no one was actually doing anything with the language, at least nothing that was in line with all the excitement about the language itself. There were no revolutions waiting to happen." from https://prog21.dadgum.com/128.html And "When I still followed the Usenet group comp.lang.forth, I wasn't the only person frustrated by the lack of people doing interesting things with the language. Elizabeth Rather, co-founder of Forth, Inc., offered the following explanation: there are people solving real problems with Forth, but they don't hang-out in the newsgroup. She would know; her company exists to support the construction of commercial Forth projects." from https://prog21.dadgum.com/143.html People who are getting things done are not wasting their time discussing what language is better, anon. They are getting things done.

>>31885 >more documented Yet, we keep getting 'code as document'.

>>32208 I really like F# but I doubt I'll ever get paid to write anything in it. F# has middle child syndrome. Its always the last to get anything in .NET. You wanted MVU when MAUI saves GUI in .NET? Well too bad MAUI is like kicking dead whales down the beach and you get nothing! We are never fixing XAML. I wish there was a good way to make mobile apps in F# but the best there is is Fabulous and its terrible for making GUIs with. What is the point of even being on .NET if you don't get anything useful out of it?

Crystal is probably the most comfortable language I've ever used, probably would feel the same with ruby.

>>34242 Tell me more. I hear it's really fast.

Most beautiful language? Ofcourse it is Rust!

Bitches don't know about Logo.

>>30364 It's just Ruby but with tolerable performance

>>30364 >Elm no infixr lol

I dare anyone to say JavaScript

>>34504 Everybody unanimously already agrees on it, so nobody mentions

>>30364 While you can make any language look ugly, the most beautiful is assembly. The raw simplicity of it is unmatched by any other higher level language

>>34535 >The raw simplicity of it is unmatched by any other higher level language Almost every assembly I've used has had loads of instructions and a bunch of weird syntactic sugar over different things. Something like Scheme is much simpler – its syntax is more regular, it likely has fewer primitives than a given assembly does instructions, and the things you most commonly wish to do are accomplished with a much smaller amount of code in Scheme than in assembly. The final and most obvious test would which is easiest to learn. If someone is new to programming, I would much rather teach them Scheme than assembly.

>>34535 Assembly is only as simple and beautiful as the underlying machine is. The 8086 family is better described as quick and dirty rather than simple and beautiful. >>34542 >Something like Scheme is much simpler – its syntax is more regular Assembly should be rigid and regular, to the point of tediousness. But then again, this depends on the machine. >it likely has fewer primitives than a given assembly does instructions And it has more primitives than another given assembly does instructions, that proves nothing. >and the things you most commonly wish to do are accomplished with a much smaller amount of code in Scheme than in assembly. If you are writing assembly then you are probably not trying to write less code. >The final and most obvious test would which is easiest to learn. Assembly or rather machine code is easier to rationalize than scheme, it follows simpler rules, programming languages have to follow those rules and others on top. It is also harder to memorize because it is farther away from natural language and mathematics, it is more arbitrary as it is designed around hardware. Anyways assemblies are just application specific and inflexible macro processors, general macro processors are perhaps more beautiful than assembly, here is an example https://www.ml1.org.uk

>>34549 >And it has more primitives than another given assembly does instructions, that proves nothing. The lambda calculus has only one primitive, and is also quite high level. I think this is quite reasonable to bring up given that your defence of assembly is based on a hypothetical version of it that doesn't actually exist (or at least hasn't existed for quite some time). >it follows simpler rules Wrong. Assembly follows many complicated rules to mimic hardware, Scheme abstracts these rules and presents a much smaller and more consistent interface. >programming languages have to follow those rules and others on top They actually don't because of Turing completeness. >Anyways assemblies are just application specific and inflexible macro processors An assembly is a set of rules for executing the listed mnemonics moreso than the mapping from those mnemonics to machine code. You are describing assemblers, rather than the languages they process. Assemblers are macro processors, assemblies are not. You are confusing "simple" with "low level". While an assembler would likely have a simpler implementation than a Scheme interpreter, the later is considerably more simple in usage.

>>30364 If we're just talking aesthetics, probably C. It's simple enough that you don't get the line-noise of something like C++, but at the same time it's got a lot more variety than the likes of Lisp. That's not to say that C is my favorite to program in, I just think it looks nice

>>34550 >The lambda calculus has only one primitive, and is also quite high level. Lambda calculus is not a programming language. >your defence of assembly is based on a hypothetical version of it that doesn't actually exist (or at least hasn't existed for quite some time). One Instruction Set Computers do actually exist, but why compare primitives with instructions? instructions are a component of the Von Neumann architecture which is the one that defines the primitives in this case. >Assembly follows many complicated rules to mimic hardware Assembly follows the rules defined by hardware which in turn may be complicated or not. >Scheme abstracts these rules and presents a much smaller and more consistent interface. Programming language implementations don't abstract the ISA, they try to make a functionally equivalent programs. Scheme was not developed with the intent of having a smaller interface than assembly, it would be impractical if it did, while assembly tries to be the smallest complete interface to an ISA. Consistency is more of a question about if the language has undefined or implementation-specific behavior and higher-level languages are more prone to this kind of inconsistency. >They actually don't because of Turing completeness. Turing machines can't physically exist. >You are describing assemblers, rather than the languages they process. You are right, my intention was stating that assemblies are macro languages. >You are confusing "simple" with "low level". Simple is low level, can you know with certainty what the execution of a given program would be like? in assembly you can by reading the ISA specification while in scheme you would have to read the implementation on top. >While an assembler would likely have a simpler implementation than a Scheme interpreter, the later is considerably more simple in usage. I'm not denying that, ease of usage has nothing to do with simplicity, for example binary is simpler than decimal however decimal arithmetic is easier for most people. Also simple doesn't mean better, the original Lisp was simpler than Scheme and Scheme is the better language. The simplest program is one that does nothing, the simplest language is one that can't express anything, you won't do anything if all you strive for is simplicity.

>>34559 >Consistency is more of a question about if the language has undefined or implementation-specific behavior and higher-level languages are more prone to this kind of inconsistency. This is the opposite of true. Machine code is filled with undefined behaviour, sequences of bits that may produce errors or do lord knows what else. C has much less by contrast, and Scheme has none as far as I'm aware. Higher level languages are usually more consistent and defined than lower ones. >Simple is low level The opposite actually. For instance, it's much simpler to edit ".docx" files in the high level Microsoft Word than a low level hex editor. >ease of usage has nothing to do with simplicity From the Cambridge English Dictionary: >simple adjective (EASY) >easy to understand or do; not difficult >in assembly you can by reading the ISA specification while in scheme you would have to read the implementation on top. What magic guarantee do you have that your computer follows the ISA spec if you don't trust the Scheme compiler? It's pretty common for CPUs to have bugs in them actually, so you better look through the entire CPU circuitry to make sure. Once again you seem to have misunderstood what a programming language is. The specification defines the language; the existence of a compiler is purely incidental. You shouldn't look at how a compiler is defined when writing programs because then you will be writing in that compiler rather than in the language defined by the spec. I think this misunderstanding is the source of your issues about assembly. Instead of viewing it as a language and treating it like any other, you view it as something that just exists by virtue of the computer itself existing. In this way it is beyond criticism. If the computer natively executed lisp instructions, that would make lisp simpler than assembly by your definition, yet nothing would have changed about either language. The language and its simplicity are entirely divorced from the platform it runs on.

>>34560 >Machine code is filled with undefined behaviour, sequences of bits that may produce errors or do lord knows what else. Then your machine is defective, if using a defective machine you should abstain from using instructions that incur in UB. >Higher level languages are usually more consistent and defined than lower ones. Higher level languages have more flexibility and therefore more inconsistency, for better or for worst. >From the Cambridge English Dictionary: >>simple adjective (EASY) >>easy to understand or do; not difficult That isn't the kind of simple i was talking about. >What magic guarantee do you have that your computer follows the ISA spec if you don't trust the Scheme compiler? I can trust a Scheme compiler without reading its source, that's different from understanding what it does. >It's pretty common for CPUs to have bugs in them actually, so you better look through the entire CPU circuitry to make sure. Are you bug ridden by executing Scheme in a buggy CPU? >You shouldn't look at how a compiler is defined when writing programs because then you will be writing in that compiler rather than in the language defined by the spec. You should if you are interested in a program's execution. Also there are some limited cases when writing code for a specific compiler is excusable. >Instead of viewing it as a language and treating it like any other, you view it as something that just exists by virtue of the computer itself existing. Assembly is just a macro language, machine code actually exists by virtue of the computer itself existing. >If the computer natively executed lisp instructions, that would make lisp simpler than assembly by your definition That would make lisp the simplest language you can use on that computer, not the simplest language that exists. >The language and its simplicity are entirely divorced from the platform it runs on. What I am concerned about is simplicity of execution because simplicity of expression will always be subjective.

>>34562 >Higher level languages have more flexibility and therefore more inconsistency Sorry, that doesn't follow. You need to define inconsistency, then define flexibility, then explain how one leads to the other. High level languages are almost always less flexible than assembly because they don't allow you to do some of the things which assembly permits. A key property of assembly is that it can easily emulate any other language; surely a language which can emulate any other with ease is the most flexible of them. >Assembly is just a macro language, machine code actually exists by virtue of the computer itself existing. >That would make lisp the simplest language you can use on that computer, not the simplest language that exists. The language exists because someone designed it, and there being a machine to execute it is purely incidental. It follows that any properties of the language are independent from the machine that executes it. This would mean any references you've made to computers, ISAs, compilers, macro processors, etc. are both invalid and irrelevant to the question of a language's simplicity. >What I am concerned about is simplicity of execution because simplicity of expression will always be subjective. So you are judging based on something irrelevant because the useful metric would be too subjective?

>>34564 Are you serious? The whole purpose of machine code IS to run on a physical computer in the real world, its not incidental. Computers exist in the physical world and are bound by physical limitations, thus machine languages are designed with physical limitations in mind for better efficiency - speed, energy consumption, heat, throughput, etc. Furthermore a specific computer can ONLY execute its own specific machine code - that's ALL it can do. Interpreters can be built that run on that machine code which then execute interpreted instructions, compilers can be built which have their own system of instructions which emit machine code. But fundamentally it remains the same regardless of where code comes from - a computer can do is execute its own specific machine code.

>>34565 >The whole purpose of machine code IS to run on a physical computer in the real world, its not incidental. It isn't incidental to the designers of the assembly of the computer that executes the machine code, but we are neither of them and we are not discussing the design of computers. It would obviously be relevant if we were discussing the execution of programming languages, but we are discussing the languages themselves which clearly exist independently of their execution by virtue of the fact all of them had to be created before they could be executed. >Furthermore a specific computer can ONLY execute its own specific machine code - that's ALL it can do. And? You've spat out a bunch of random facts which I already know and not really come to any conclusion.

>>30372 Wow, you sound like a very frustrated person. Maybe you should take a break from programming and go outside for some fresh air. Or maybe you should try Lisp, the most powerful and elegant programming language ever created. Lisp is not just a language, it's a way of life. It's a philosophy of programming that transcends the mundane details of syntax and semantics. It's a language that lets you express your ideas in the most natural and concise way possible. It's a language that lets you manipulate the language itself to suit your needs. It's a language that has been used for decades to solve some of the most challenging problems in artificial intelligence, computer graphics, natural language processing, web development, and more. Lisp is not just interpreted or compiled, it's both at the same time. It gives you the flexibility of interactive development and the performance of native code. It can run faster than C or something , because it has advanced features like macros, multiple dispatch, tail call optimization, garbage collection, dynamic typing, first-class functions, closures, continuations, multiple inheritance, generic functions, meta-objects... I could go on but I don't want to bore you with facts. You say that nothing is done with Lisp? That's nonsense. Lisp has been used to create some of the most innovative and influential software systems in history . Do you know Emacs? AutoCAD? Macsyma? Mathematica? Reddit? These are all written in Lisp or inspired by Lisp. Do you know Paul Graham? John McCarthy? Peter Norvig? Richard Stallman? These are all Lisp programmers or advocates. Do you know what they are up to now? They are changing the world with their ideas and creations. You say that we are reinventing wheels with different libraries? That's not true either. Lisp has a rich and diverse ecosystem of libraries that cover almost every domain imaginable. You can find libraries for web development, data analysis, machine learning, game development... You name it, Lisp has it. And if it doesn't have it yet, you can easily create it yourself with macros and libraries. You say that we are dying and dead? That's hilarious. Lisp is alive and kicking. It has survived for over 60 years and it will survive for many more years to come. It has evolved with the times and adapted to new paradigms and platforms. It has inspired countless other languages and programmers. It has proven its worth time and time again. You say that all of this is a distraction at best? That's sad. You are missing out on one of the greatest joys of programming: exploring new possibilities with Lisp.

>>34567 >[Lisp] can run faster than C or something , because it has advanced features like... garbage collection... garbage collection is horrendously slow, its a large amount of additional computation, it thrashes the cache, it causes memory fragmentation >>34566 We are using real physical computers that inhabit the real world. The physical nature of computers effects how they are programmed, and the results of programming languages used on them. Anyone programming in assembly is clearly intending for their code to be executed on a physical machine. You cannot separate a language from the environment it exists in.

>>34559 >Lambda calculus is not a programming language. How is lambda calculus not a programming language when it is so easy to construct a Turing machine with it. That and most sequential programming languages can be understood in terms of lambda calculus. > Consistency is more of a question about if the language has undefined or implementation-specific behavior and higher-level languages are more prone to this kind of inconsistency. According to Cambridge’s dictionary : “the quality of always behaving or performing a similar way, or always happening in a similar way”. In that sense, a consistent language is not necessarily one with a pure clean vision of itself in which the programmer can guess at syntax because they understand the general syntax principles to which the syntax adheres. When we talk about consistency in a computational language we usually say that, given a sequent claiming the witness of a proposition of equality of terms then we can derive that the two terms have the same value by computation.

>>34568 >You cannot separate a language from the environment it exists in. I can. >garbage collection is horrendously slow, its a large amount of additional computation, it thrashes the cache, it causes memory fragmentation Almost all of this is wrong, and some of it is laughably wrong. >>34569 >How is lambda calculus not a programming language when it is so easy to construct a Turing machine with it. He thinks programming languages are the same things as their interpreters and since he isn't aware of an interpreter for the lambda calculus he thinks it isn't a programming language. It's a perfectly consistent (yet incredibly stupid) perspective.

Recently fell in love with common lisp due to the different approach to development and the complete disregard to established cycles. What the industry calls "agile" is utterly ridiculous and only extends to methods, development itself boils down to improvisation. Wishful thinking like XP only serves to reinforce the outright fact that what is considered modern has become legacy. We need stuff like lisp, elixir or haskell. Anything that encourages an incremental and interactive approach.

>>34581 I agree whole-heartedly with that sentiment. You can't use garbage technology and expect a soykaf methodology like Agile, etc to carry you. If you want real progress and improved software you must use tools that allow you to write such things easily. The nice thing about a statically typed FP language is that it allows the developer to more easily iterate and improve. Because of this, I am submitting OCaml to this list. It is the most beautiful language I have ever written.

>>34582 Didn't really like OCaml when I tried it myself. However, I am fairly certain that it's purely due to taste, because what it does is very much solid. Syntax is just not my cup of tea. Reading your post now makes me realize, though, that we're literally talking about using solid tech to compensafe for soykaf methods. Then again, if a project actually used tech to match that methodology, it might turn out to be a decent idea anyway. I can only speculate. The only company nearby that uses any of the languages mentioned, which would be CL, isn't hiring. Little spark of hope though. Got a new suit recently, matching the ragtag band of misfits that makes up our team. We got weekly meetings where we can present anything that might be interesting to our occupation. I got green light to go with Common Lisp. And I plan to present remote debugging and do my best to make Java's class hotswapping (read: coin toss between undefined behavior and crashing) and 5 minutes of rolling release look like children's toys.

>>34585 That is a good accomplishment lain! I've been trying to get my co-workers and team interested in OCaml (or literally anything other than Java), but it's been an uphill battle. I work at the peak of enterprise tech, Java, SAP so it probably won't change until I feed a new job (or make a startup). Still proud of you though, show them the power of alien technology.

>>34592 Our field has its perks, we're spearheading a bit within our company. Of course, that also severely limits our application of the concept as we work with drones a lot, but at least there's some wiggle room. I'm talking all-out no-stepping-out-of-comfort-zone drones, not people who are forced into using mediocre languages. Also helps that my colleagues are a collection of adventure stories. >people who fled from war-torn countries and clawed their way into IT by willpower alone >one guy who ran a company until he got Steve Jobs'd by his partner >dude who barely got through high-school, got no further education, taught himself the ropes and saved up money for certs >guy who was on probation for being involved in a student riot, at least he claims it was for that At times I feel like I need to break an officer's nose just to fit in.

>>34581 Haskell does not encourage incremental development. You should work with haskells or OCaml folks some time. If it's an OCaml project you don't control, good luck getting the top level (REPL) to work properly. Haskell fairs a bit better, but the codebases aren't written in a very incremental style Further the tools given for abstraction does go against an incremental style when used in someone's hands who does not understand the value of incremental and interactive development, often components and scaffolding is thrown down that can't be properly ran or used until large scathes of work is already done. Ft a lainon who worked professionally in OCaml and haskell

>>34567 This is gonna make a cool copypasta, if it isn't already, lol.

>>34594 Will cede that I have no experience on OCaml, but for Haskell the potential is definitely there. Pales when compared to anything Lisp, but that's never a fair comparison because poking at, experimenting with and evaluating individual expressions to test, expand, improve and weld together is the name of the game with those. I'm sticking with it for now. I got the chance to give it some spotlight and I intend to go laser-guided for now. Since cloud development is a current trend, I'm focusing on that. Intend to grab the SBCL docker container and build a complete pipeline to deploy a hello world web application to ECS. Shouldn't be too hard, because the pipeline won't be doing much in the first place. Lisp applications generally fetch their dependencies and deploy themselves.

>>31717 >C89 Must second this. I started a C89 project for fun ~2 months ago, and it definitely feels beautiful. My mental model of my program is significantly closer to what it will actually do than with any other high-level language. And having all declarations at the beginning of functions looks so pretty. Though, I must admit, writing a hash table for the nth time is not very practical, I'm more productive in other languages. But it's beautiful. >>31767 APL looks like line noise to me. I've always wanted to learn it, but I never have project ideas where I feel like "ah, this would be nice to write in an array programming language". >>34504 >JavaScript Modern JavaScript is beautiful. Of course, node/npm dependency hell, the web APIs and other frameworks are cancer. The core language though, used as an embedded scripting language (e.g. with QuickJS), is pretty nice. >>31489 >Nim Definitely looks clean, and macros are a tremendous help for productivity. Unfortunately, said macros very easily get quite ugly (AST manipulation functions are crap). And the compiler is a bug ridden mess, filled with weird, unspecified behavior. So the language doesn't really qualify in my eyes as "beautiful". Despite these issues, I still get soykaf done with it more quickly and in less lines than with anything else, which I find very annoying. I wish there was a language as good as Nim that had a properly working implementation... I do hope Nimskull/Cyo will reach that level one day, but so far I've only seen it segfault.

>>34644 There is a variant of nim that uses Clang LLVM for compiling. Even the creator of nim thinks this method is better but chose not to use it just because he wanted more architectures covered. As for problem with macros I think i recently heard someone describe Zig as the opposite of nim for this reason where it restricts certain features to keep things from getting too complex while nim just takes in as much as it can. Im not sure how accurate that is but i found it an interesting way of comparing them.

>>34644 >>34646 https://lobste.rs/s/zrb6vm/i_learned_7_different_programming#c_ctlczq is quite worrying concerning Nim, though.

>>34571 A programming language _is_ an implementation. Restated: a programming language is defined by that which recognizes it. This can be a compiler, an interpreter, etc. The "lambda calculus" isn't a programming language by definition, it is merely a calculus.

>>34651 I've just written an interpreter for the lambda calculus. It is a real language now by your definition.

>>30364 lua <3 local M = {} local zipgen = function(args) -- find minimum local min = #args[1] for i = 2, #args, 1 do min = #args[i] < min and #args[i] or min end -- create list with 'i'th element from all iterators for i=1, min do local ans = {} for j=1, #args do -- get 'j'th iterator's 'i'th element ans[j] = args[j][i] end -- return list of 'i'th elements coroutine.yield(unpack(ans)) end end -- python like zip iterator M.zip = function(...) local args = {...} return coroutine.wrap(function() zipgen(args) end) end return M it's python's zip() in lua

>>30364 Judging by syntax only > SML > Ocaml (beside the horrible choice of using @ for string concat) > clojure > hare > ADA

>>34906 > @ for string concat ^ is string concat... @ is List concat.

>>34567 Found the Lisp wage slave. Only 10 posts in. I will say... Java. Please hold your screams in. Yes, things get convoluted, but it's still very readable. C also since it's so similar.

>>34913 >lisp wage slave such a thing exists? i thought lisp bros were all angrily working OOP or unemployed.

>>34914 Site autocorrects $hill into wage slave

>>34913 >Java >Readable You've obviously never had to touch Java in a real-world setting. I work in a Java shop, we're modernizing a large system (10 million LOC), It takes about 45 minutes to dig down and find the real definition of a method, the new modernized code is a lot better, but we still run into issues with readability especially with all of the magic BS that modern Java encourages.

>>30364 C's pretty nice. It's not perfect by any means, and it definitely shows its age in some places, but on the whole it's probably the language that I like reading and writing the most. It's clean and minimalist, but not to the point where it's reductive, and it manages to be highly explicit without being ugly and verbose. Lisp is also really cool. Using it makes you feel like a programming god; like you can make the computer do whatever you want however you want in incredibly succinct terms. C edges it out a bit because I find it easier to read, but there's few languages as fun to write as Lisp. It's hard to do it justice in a post like this; you just gotta try it yourself. I also have a weird affinity for C++ and Perl. They're messes, but they're honest messes. There's something to be said for a language that puts pragmatism above all else; where you can just throw a bunch of kludge together and have it work mostly as intended. This is only the languages I know well enough to comment on, by the way. I haven't used OCaml or Forth, but they both seem good from what I've seen.

>>34929 >without being ugly and verbose Yet when you look at any real C code you start to see stuff like: library_name_struct_name_function_name(&struct); C is ugly by accident and verbose by design.

>>34930 Oh C definitely has its fair share of flaws, and I'm not going to pretend that they're not flaws. There's a laundry list of features that C lacks and I wish it had (C++ style namespaces, foreach loops, optional macro hygiene, more robust error handling, etc.). But I like C for what it is on the whole. It has an overarching philosophy of explicitness, low overhead, and known maximum resource usage, and it does a pretty good job of sticking to that philosophy. Most (although not all) of it is the way it is for a good reason, which is more than I can say for most languages.

>>34931 When you really think about it, 90% the features you interact with are just things that needed to be there. When 90% of a language is stuff you can't even negotiate, it seems like it's good. My issue is that if you look at the other stuff that doesn't need to be there – the actual features – all of them are bad. Some of them were justified at the time of C's inception, but today they are all bad. This is the trick C pulls. 90% of it is good; it is, on the whole, a good language. But almost all that is uniquely C is bad.

>>34933 What existing or future language do you propose as its substitute?

>>34945 I'm not him, but read the earlier posts in this thread concerning Ada.

>>34945 People don't really use C because they like the language. They use it because they like the stability of it, the features that exist around it, and the high portability that comes from its almost ubiquitous support. Few other languages provide anything close to this, so there is no real substitute. In terms of languages that fit the description of C but better, Zig springs to mind. It has quite good C interop and seems to correct many of the issues of C while remaining at a similar level of abstraction.

>>34945 Idk how hackers around here feel about this, but zig looks promising with respect to it's selling features - same as C (simplicity, any toaster can run it, no fancy borrowing/rtti - all is explicit, etc...) but better in terms of memory management (custom allocators, defer, errdefer), code generation (rich compile time stuff) and error handling (optionals/results are actually a thing) All in all great start, don't know however what will come at 1.0, but zig really gathering "low level + simple" system niche. I hope this language (or other like it) will replace C already

>>34950 >>34959 Sorry for repetition, somehow glazed over your post

>>34950 >>34959 Isn't Zig still a "big idea" language? Those never take off, creating a new programming paradigm has never worked

>>34966 I'd say it's quite the opposite - it has nothing new in terms of features that hasn't been implemented in major languages already. Heck, conceptually it is just refined C (for now at least). On the other hand if you are talking about all "non-profit foundation" thing and plans to replace a GOD like C - this is merely ambitious, time will set everything up. You should look fresh pitch in zig (on GOTO 2022) it's detailed enough to showcase language direction

>>34611 I think you've already ceeded the point. Think why you can't do that in Haskell. nothing about the language itself prevents it. Tools like GHCI are just interpreters over a batch compiler. This is why when you load code into it, it destroys all state and only loads the modules implied by the current environment. This in practice scales horribly, as you can't go past stack boundaries, so much so that tests don't reload properly. CL succeeds at this because it is an interactive language. It defines out an environment and makes sure that is fairly malluable. It ends up being it's own OS with a suite of tools to work over this. It's a complete language in that sense. How did your project go?

>>34979 Nowhere relevant so far. Pretty large team and my number hasn't come up yet. Probably for the best since just deploying an application isn't all that hot. Did have the opportunity to show off something in a "lightning talk" format though and that was promising. They were surprised that I could just start hunchentoot and add routes to it while it was running happily hacking away at the REPL without restarting it. But changing the function the route was bound to, pressing F5 in the browser and showing the immediate change immediately, THAT blew their minds. I even managed to get away with a "Zero downtime by restarting instances one by one? Try zero downtime by not having to restart, period." Got their gears grinding. Now I'm wondering how to top it. I kinda want to shove macros in their face, but it has to make sense in a cloud context. Generating bitbucket pipeline definitions with a DSL, maybe?

>>34998 Just don't try to explain eval-when to them and you'll be okay. How about showing some condition+restart magic or runtime compilation?

>>35005 Condition and restart magic is freaking sweet, don't get me wrong. But it'd be more useful regarding backend dev than actual cloud context, no? This is an issue with many things, actually. Runtime compilation's definitely something to look into. If everything else fails, I'll just go for remote debugging and how we could immediately apply hotfixes in production while waiting for a piece of soykaf 1.5 hour pipeline to roll it out neatly. Maybe have a separate route serve the function sources in a private subnet so "puppets" can fetch the updated ones. It ain't pretty, but definitely impressive. Especially when I share the age-old send-code-to-space story along with it. Basically mandatory at this point. All's fair in love and war. Or, in this case, giving people some perspective that doesn't involve trace amounts of Algol.

>>30364 C and C++ i will not elaborate.

>>36302 >C No elaboration needed. >C++ Many questions require an answer here.

Typescript is beautiful for me and I can build anything I want

>>37087 I would much rather use ReScript than TypeScript if we're considering beauty as a feature.

>>36308 >Many questions require an answer here. Not them, but I too find C++ somewhat beautiful. For one, it has may feature which, when properly used, can make code very clean and easily understood. Templates and operator overloading, that is. Moreover, and despite the complexity, everything is resolved at compile time, which makes the resulting program almost as fast as an equivalent C code.

>>31431 You can compile C to shared objects and use Ctypes in python to import the functions. That's my favorite way to develop programs. Python has it's good side, like compare trying to lambda sort a list of objects in Java vs in Python. In Java you have to make them implement comparable, specify a method of comparing, and then if you want to compare on something different they want you to get into polymorphism... it's much more of a hassle, just because they don't want you to pass a pointer. I like that python lets you do that by passing a reference to a python function, then send that to a sort function (written in c) that can interpret python code. It's really nice! And it's nice that you can easily make your own shared objects that do similar stuff.

I lke the way C, LUA, Nim, and Python look. I don't know much about Nim though, but it looks like the best of a lot of stuff. I always thought LISP looked gross, and never really understood why people love it so much. I get i that it was first to do a lot of things, but in the modern scheme of things (pun intended) i just don't see the benefit.

>>37351 The value of lisp has not really diminished over time. Lisp is one of the few languages with meaningful syntax (only languages without syntax can reason over themselves at the syntatic level), and can easily bootstrap itself. Hell Common Lisp is a complete system filled with ways to talk to it from the inside in the same light as Forth, APL, Erlang and Smalltalk. Complete programming environments used to be bigger, and they ought to be given, how they raise developer productivity. Thus, I'd argue you ought to open your mind about the benefits of some of the more "niche" languages. I'd recommend CL as a system, you even install packages via the REPL itself, and hot load code live, even code 50 million miles away!

>>37351 >I always thought LISP looked gross, and never really understood why people love it so much. They admire its minimalism. Clojure specifically went with syntax that added a small amount of complexity for a large improvement in readability, and people rioted. The same thing happens whenever someone proposes adding features to C.

>>37351 >I always thought LISP looked gross, One of the benefits of Lisp syntax is that almost everything works the same way. It's nearly uniform syntax for everything and you don't need to learn a lot of different special cases. All you need to learn is function call and it just works for almost everything, except the special forms (but even they don't stray far from the Lisp function call syntax). After you have learned enough Lisp (not much, actually) , you don't even see the parenthesis anymore because it's so simple.

>>37355 >They admire its minimalism It's more than minimalism. It's the fact that there is no syntax. Other languages have an AST and some way of representing it, lisp pretty much just has an AST. There are no unnecessary characters smeared over the top of the actual representation. >Clojure specifically went with syntax that added a small amount of complexity for a large improvement in readability I don't think Clojure's syntax actually makes it more readable. (let {a 12 b 13} (+ a b)) (let (a 12 b 13) (+ a b)) What's important there is the highligting on the "let" and indent of the body. The brackets around the argument list don't change much. It's not good or bad, but it is different, and I think that's the main reason people hated Clojure. >>37363 >you don't even see the parenthesis anymore I've always hated that way of framing it. It isn't that you stop seeing the parens, but that you start seeing the structure – the thing they represent.

>>37366 >I don't think Clojure's syntax actually makes it more readable. Opinions are obviously divided, but it's worth noting that the use of different types of paired brackets as an aid to readability was popularized in Scheme before it was adopted by Clojure. I don't remember what revision/implementation first permitted that convention (and it really is just a convention in Scheme, because a pair of square brackets means the same thing as a pair of parens). It might have been Racket. As with Clojure, the jury is still out on whether Scheme and Racket count as Lisps.

>>37369 I've never seen any Scheme code actually using square brackets, so I would guess that they aren't worth it. You can just turn on rainbow-parens and have every nested pair highlighted a different colour which is a lot better than just having the brackets a few pixels different. Maybe it does improve readability, but it does so in a way that's both marginal and redundant.

>>37382 >just turn on rainbow-parens It is debatable whether a language that requires a special editing environment is more accessible than a language that does not

>>37383 It's laughable to see this opinion here. The purpose of a computer is to compute. Use ed and get back to us.

>>37385 I have one word for you. Blind programmers.

>>37387 The fact that most programming happens in text editors rather than visual environments is a condemnation of the so-called state of the art. Forcing everyone to program like a blind programmer just handicaps everyone else.

>>37387 >presents great can opener design >but can it be used by quadruple amputees? Sir please. I dont want blinds to be screwed over if its at no cost, but like, they're not that common. If its handy its handy and the blinds can go write in whatever language they like.

>>37383 >requires a special editing environment All languages require an editing environment because you can not interface with the bits on your disk directly. If you choose one not specialised for the language you are using, the user experience will be worse. This is also true of all languages. The advantage of lisp has always been that it is good on a cooperative editor rather other languages which target editors hostile to them. It's stupid to cater to the lowest common denominator of users willing to use the language but not willing to install an editor plugin.

>>37387 Current programming language syntax and input mechanisms are probably the most hostile to blind programmers: void main, open parentheses, int arg-see [or "aye are gee see", or "argk"], comma, char-star-star [asterisk-asterisk] arg-vee [aye are gee vee], close parenthesis, open curly bracket....

>>37387 With proper systems and minimal syntax, you could think of proper projections of lisp or forth syntax for blind programmers. Since syntax isn't holy, users could make this themselves, as you can walk syntax, and if it's stored in an image you can do this for any function that is defined in the system. If anything the text based way where we throw away all information and don't make an environment is worse for trying to create tools for the blind.

Currently for me it would be Haskell. I feel like it can be really elegant at times when it all comes together but when it doesn't it's really ugly (though it's not always fair to blame the language).

>>31591 Pythons object model is basically Java's object model, except for the fact its 25x slower. Unfortunately Python has been doomed by becoming the get out of Java language, meaning most things are omega object oriented nowadays when in the old days of Python there were major pushes to get away from that.

>>30364 My vote is for OCaml. Its got a lot of "clever" high-level functional features that it expects you to use a lot, but unlike, say, Haskell, it's generally not to the point where it becomes esoteric and/or detracts from the language's practicality. It also produces very nice looking, highly readable code. I also like Perl in a sort of guilty pleasure way. It's a complete mess, but I like how much it commits to the mess. It's just so aggressively a hacker's language, you know? >>36308 C++ is the only mid-level language I can think of that claims to be practical and actually is. It lets me do in less than a day what would take me nearly a week in C with more-or-less the same performance. I wouldn't exactly call it beautiful, but it's not really trying to be. It's goal is to be useful, and for the most part it succeeds. >>37394 I disagree. Code, especially high-level code, isn't just a list of instructions for a computer to evaluate; it's also a form of mathmatical/logical notation to be read and written by human beings. A lot of my best code has been functions I've jotted down on paper or in my phone's notes app and then fed to a compiler/interpreter/whatever later. Like it or not, Lisp's syntax doesn't exactly lend itself to chalkboard programming.

>>37442 >Like it or not, Lisp's syntax doesn't exactly lend itself to chalkboard programming. Here's a thought: what if you write code on paper in a syntax that works well with paper, and on computers in a syntax that works well with computers? Usually these aren't the same, and the name for the paper one is pseudo-code. People have actually been doing this for quite a while – longer than programming languages have existed – so how this innovation passed you by I'll never know. Lisp's syntax is uniquely situated to be easily translated into other forms. The code and underlying representation are the same tree structure, which you could display in any format you want. It therefore stands to reason that you could write this tree on paper in any way you want and do the reverse translation when entering it into a computer. Lisp even has macros which would allow you to enter any symbols from the paper definition not already present in the language.

>>37442 How to learn OCaml? It's seems so strange and alien! Should I learn SML first? What books/tutorials do you recommend for OCaml and/or SML? Is F# a superset of OCaml (like C++ is for C99).

>>37453 I learned OCaml the way I learned every other programming language; by trying to solve simple problems with it and looking up tutorials when I get stuck. I suggest starting by writing a program that prints the mean, median, and mode of a list of integers. That'll teach you the bare basics of the language that you need for day-to-day programming, and you can fill in the rest of the knowledge as you go.

>>31754 any recommendations for how to handle inverting multi-diagonal matrices? Keep searching for solver methods but I keep just getting recommendations for cholesky decomp, which doesn't seem right for sparse matrices but I'm kinda dum.

>>31608 >if you write it that language becomes a popular language because people have to learn it to maintain your code. a little ambitious. >also if we followed your logic we would all be using Fortran because it was the first language, and therefore everyone should have used it. No, because better languages *very slowly* grew in popularity and supplanted it.

>>31715 This is the only right answer ITT. Haskell is literally a better designed, slightly higher level language than anything else that's mainstream (there are other research langs like Idris but I don't want to get into that).

>>38334 Well designed, maybe, but beautiful absolutely not. Haskell code seems to uniquely resistant to being written down. Whenever I see a Haskell file, I think of words like "mangled" or "smeared" instead of "beautiful". It's really awkward in that it's full of all these runes and nowhere clear to put them. A lot of variables are given very undescriptive names and a lot of code is written to avoid any variable names at all.

Erlang has always been the most beautiful languages to me. I use Elixir more often than Erlang because it has good, modern tooling and thus isn't as big of a pain in the ass as writing Erlang is, but the whole period, comma, semicolon thing Erlang has going on just makes sense in a way that most languages don't. Commas for a sequence of expressions (X = 1, Y = X + 1 -- used like a semicolon in C-like languages), semicolons for related expressions (separating alternate function heads for pattern matching), periods for the end of a entire expression (signals the end of a series of alternate function heads). C-like languages have poisoned the mind so much that programmers can no longer see the beauty of Erlang and it's soykaf. Haskell is probably the closest second.

think nothing is as visually beautiful as assembly. it wears no mask of semantics and shows no signs of human pretension.

>>38348 >it wears no mask of semantics and shows no signs of human pretension. That would be machine code. An assembler language is filled with ugly little chants and invocations that only get in the way. Compare any assembler language with this.

>>34567 use something other than gpt mate

>>38348 it does though, because something like MOV, is actually 10 different machine codes and the assembler deduces which one to use based on if it's moving from a memory address to memory address, or to register, or if it's an immediate address or a other type. >>38349 microcode ruins machine code idolatry

>>38428 >it does though, because something like MOV, is actually 10 different machine codes and the assembler deduces which one to use based on if it's moving from a memory address to memory address, or to register, or if it's an immediate address or a other type. Yes, that's a characteristic which the tool on display makes known. >microcode ruins machine code idolatry The tool was originally envisioned as a development environment for horizontal microcode.

>>38428 >microcode Microcode is not "microps" or whatever representation instruction block would create from architecture instructions. Microcode is a way to alter circuitry by programming for example instruction decoder PLA etc.

Black is the most elegant Lisp, nothing even comes close to its poetic core

I wanted to make a post in the APL thread, but that thread no longer exists, and I just now realized this. I was the only person who posted in it anyway. I may not have remade it since the last time it died, years ago, now that I think about it. I've written a Wordle solver in APL, and wanted to mention it somewhere in this board. Here it is: d←'abcdefghijklmnopqrstuvwxyz' ∇ wordle l;⎕IO;g;i;s;w ⍝ I have l for list; g for guess; i for index; s for summary; and w for word. ⎕IO←i←1◊s←+/d∘.=w←l[?↑⍴l;]◊'Word: ',w now: ⎕←g←l[?↑⍴l;]◊→end⍴⍨g≡w◊i←i+1◊l←(((+/[2]l∘.=d)∧.≤(6,⍳5)[1+(s<+/d∘.=g)×s⌊+/d∘.=g])∧((+/[2]l∘.=d)∧.≥s⌊+/d∘.=g)∧(((g=w)/l)∧.=(g=w)/w)∧(((~g=w)/l)∧.≠(~g=w)/g)∧(~∨/(l∊(~g∊w)/g)))⌿l◊→now end: 'Guesses: ',⍕i ∇ Here's code that reads in the dictionary, without any error checking: dictionary←⎕FIO[26] 'five-letter-words' dictionary←dictionary⍴⍨⌽5,⌊5÷⍨⍴dictionary ∧/,dictionary∊d ⍝ This line will result in one if the dictionary be valid by d, or zero otherwise. Here's the writeup: gopher://verisimilitudes.net/12024-08-27 http://verisimilitudes.net/2024-08-27 Here's a solver I wrote in Common Lisp: >>39805

>>39898 this is... it is something. glaring into it's symbols and 0xEF I can almost gleam a shining ray of light... God? is that you?

>>39899 This form, also listed in the writeup, may be easier to understand, or at least to view: ∇ wordle l;⎕IO;g;i;s;w ⎕IO←i←1◊s←+/d∘.=w←l[?↑⍴l;]◊'Word: ',w now: ⎕←g←l[?↑⍴l;]◊→end⍴⍨g≡w◊i←i+1 l←(~∨/(l∊(~g∊w)/g))⌿l l←(((~g=w)/l)∧.≠(~g=w)/g)⌿l l←(((g=w)/l)∧.=(g=w)/w)⌿l l←((+/[2]l∘.=d)∧.≥s⌊+/d∘.=g)⌿l l←((+/[2]l∘.=d)∧.≤(6,⍳5)[1+(s<+/d∘.=g)×s⌊+/d∘.=g])⌿l◊→now end: 'Guesses: ',⍕i ∇ Rest assured, this one line is very well documented.

uxntal for uxn is pretty awesome, surprised it wasn't metioned yet very minimal programming stack which is intended to be super portable. has emulators for gameboy, Nokia n900, Nintendo DS and bunch more still being made https://wiki.xxiivv.com/site/uxntal.html https://100r.co/site/uxn.html https://github.com/hundredrabbits/awesome-uxn#emulators https://www.youtube.com/watch?v=rTb6NFKUmQU

>>39911 Looks kind of like Forth. Definitely interesting.

>>39911 >>39916 its cool, but isn't it more designed for interactive media than regular usage.

>>30365 What really struck me as clever back in the day was how Larry Wall introduced object orientation to his language by adding a single keyword: bless. He distilled the essence of what it means to be OO so succinctly with a keyword that associates behaviors with data. I don't know if you could call that beautiful, but it is clever, and it still brings a smile to my face. Perl is fun like that, and that's why I keep going back to it.

>>42044 Sounds a bit like what you can do with Tcl's `objdefine $myobj class class_name` (https://www.tcl-lang.org/man/tcl/TclCmd/define.htm).

Please, take me out of a doubt... For all the people who prefer functional languages like LISP, Haskell, Elixir, OCaml, among others: Do you enjoy (beautiful) Mathematics very much? The syntax of these languages is extremely inspired by mathematical notation and focused on the declarative paradigm. So, I'm really curious if the Lains who choose these languages also relish mathematics as a second profession or hobby. It's just... “scientific curiosity”.

>>42070 >The syntax of these languages is extremely inspired by mathematical notation Except the brain damage called "infix operators and prefix functions because... reasons" and using one-letter variables everywhere, right?

Combinator calculus. It is very, very simple yet elegant. You have expressions consisting of just combinators. Reducing an expression is done iteratively by applying the outermost combinator on the left until not enough arguments are available. A popular set is the SKI combinators: - I is λx.x - K is λxy.x - S is λxyz.xz(yz) Examples: - II -> I, IK -> K - KSI -> S, KKS -> K - SKSI -> KISI -> II -> I You can define new combinators from this set. Two very useful ones are True and False: - T = K = λxy.x - F = SK = λxy.y With this, you can implement branches. With a flip or "if" combinator λxyf.fxy you can implement conditional branching. How do you do I/O? After mulling on this for a bit, I believe the most sensible option is the use of custom, special symbols. For example: - if (print "Hello, world!") exit Here, print and exit are special symbols and if is just a regular combinator. Applying T will print, applying F will exit. But how do we represent the string? We could have special symbols for bits too, but not only is that ugly, it is also unnecessary. Consider T, F and flip again: T and F can represent 1 and 0 respectively and flip a storage cell with two elements. With that, we can build and query a binary tree. To figure out whether we have the equivalent (not equal!!) of a T or F we can simply apply two distinct symbols to them and see which one we get back. (And if neither, it's an error).

>>42070 My favorite language is lisp, because it is a very mathematical kind of language. Yes, most people who are attracted to these langauges are people who enjoy mathematics. I am in fact more interested in mathematics than in writing computer programs.

>>39898 >>39900 I really wish there was an APL with easy C FFI.

>>42070 I know soykaf about maths to be honest. I like lisp, because since everything is an expression I can do retarded soykaf scott-free and don't have to burden myself with understanding stuff like operators, return values, statements and so on. I can just `(foo ...)` away.