(untitled)

What are some examples of a language/framework being perfect for a particular task?

Postscript. yeah it's too short or empty, but what else can I say? Go try it out I guess? it's ~ * P E R F E C T * ~

>>31320 This would be useful for happy birthday scripts

Inform (7). I can't say I like it, but there's a reason it dominates modern interactive fiction— it's perfect for its task and compiles down into portable formats.

Maybe I'm just happy with finally migrating my vimscript to lua but lua is a perfect language for its narrow domain.

>>31435 This, the included IDE is pretty good too. The folks behind Inform really know how to sell their language.

>>31314 C You see, it's great for its narrow domain of writing operating system kernels and nothing else.

>>31468 This. I gotta say it, it's a great language, but it really is no good outside it's domain.

C is perfect for everything. Its efficient, low-level, supported everywhere in existence, has a rich ecosystem of tools and learning resources, and feels comfortable to me. I can tell with reasonable accuracy what the assembly code will look like after compilation based on raw C code and the compiler/parameters I'm using.

>>31471 No it's not. In hindsight, if C had smart pointers, we wouldn't have problems like Firefox still having goddamn memory leaks (like I just experienced yesterday, which seems to happen once every two months or so).

>>31471 I like C, but I hard disagree. When I program, I don't want to worry about anything outside of the problem domain of whatever I'm doing. I shouldn't have to fiddle around with low-level resource management if I'm writing, say an image viewer.

>>31472 Isn't firefox mostly written in rust now?

>>31477 About 10% of Firefox code (*all platforms counted) is written in Rust (https://4e6.github.io/firefox-lang-stats/). And even if Firefox was 100% Rust, it could contain unsafe code (https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html) which voids the safety of Rust. *https://news.ycombinator.com/item?id=30743577 >inb4 posting the yellow site I know...

>>31479 Unsafe Rust voids the safety of Rust within specific, unsafe blocks which should be used judiciously and only when necessary. That's still a great deal better than C++ which is %100 of the time.

>>31472 I guess you can always just make your own smart pointers. They will also work exactly how you would want them to instead of settling with something that is premade for you.

>>31479 >which voids the safety of Rust Do you really know what unsafe is?

>>31482 No, but I assumed it's same as in C# or close enough. If I'm mistaken, please enlighten me. If you use unsafe code in C#, you have all problems that pointers generally have (even stack overflows) and that you need to free/dispose everything like in C/C++.

>>31481 C makes it hard to do something like that in a clean way because of its gimped macro system.

>>31483 While I never developed an application or system in Rust (and so please correct me Rust users where I get this wrong), I understand there's a strawman (sometimes posted by Rust detractors, other times by the Rust Evangelism Team) that 100% of all Rust code will 100% provably-by-the-compiler be memory-safe. If a Rust program uses invokes no `unsafe` blocks at all, this is true; however, there is some code which is safe, but Rust's type system cannot possibly determine if it is -- such as someone using C bindings to the API spec, or funky hardware/kernel stuff. The `unsafe` keyword lets a programmer tell Rust, "I know what I'm doing", access unsafe features, and pave the way to a safe abstraction over an unsafe mechanism. You are correct in >>31479 that Rust could contain unsafe code. But now, memory unsafety is limited to those unsafe blocks, as opposed to the C/C++ in Firefox that Rust yearns to replace, which is never safety-checked to the level that Rust is.

>>31483 I'm not sure about C#, but at least in the case of Rust, segregating unsafe code into special blocks helps an absolute ton with debugging, as it narrows down where you need to look when certain things go wrong.

>>31472 Blame bad programmers, not the tool.

>>31468 >>31471 I can't decide which of these soykafposts is better bait

>>31500 What you have to understand is that most programmers are and always have been mediocre. When you have a large-scale project, most of your staff is going to consist of mediocrity simply because there aren't enough good programmers to go around. Tools need to corral these people into doing the right thing. Otherwise, you have giant programs used by tons of people with giant glaring flaws.

>>31505 >What you have to understand is that most programmers are and always have been mediocre Hello Mr Tautology

>>31506 This is a lainchan thread, not a serious intellectual debate.

>>31507 WELL I AM A SRS INTELLECKCHUAL

Rust is perrfct for locale-dependent code because it's UTF-8 (the best encoding)

>>31483 Okay, so basically, unsafe allows you to derefrence raw pointers and use unsafe functions. Unsafe functions allow you to manage memory on a low level. Ownership still works in the unsafe blocks. As another lainon said, you tell the compiler that you know what you are doing. Rust standard library is like 50% consists of unsafe blocks but it was proven with Coq, that it is absolutely safe

>>31314 APL is an ideal language for manipulating arrays; it's very concise, its specialized notation looks like what it does much of the time, and it has about every operation one could want or need for what it does.

>>31477 Rust, even without the use of any unsafe blocks, can still result in memory leaks. It's a lot easier for that to happen in C than in Rust, since in C that's as simple as forgetting to call free, whereas in Rust, it takes implementing some anti-patterns that almost certainly are workarounds from bad programmers for compiler errors. polite sage for off topic

>>31314 bash is the best for writing UN*X tools that have all the UN*Xy bugs you expect. it would be extremely weird and uncomfortable to use a UN*X tool that doesn't have 7 ways to shoot yourself in the foot with RCE, given a single input from an untrusted source looks like yall niggaz need some sense beatin into ya >>31471 want a jpeg library? oh just use longjmp oMG such a rich ecosystem >. I can tell with reasonable accuracy what the assembly code will look like after compilation you dont even know about signal_safety(7) let alone anything a modern C compiler does you dildo fuarrrking charlatan >>31472 firefux is dogsh1t software and will continue to be so regardless of language >>31500 except when the tool is C and makes it almost impossible to write functioning code (where functioning means, goes 5 minutes without crashing, outside the autistic devs particular workflow and machine).

>>31314 C and C++ for writing systems software.

>>31314 Coq for proving correctness.

C is perfect for LARPing while being the worst possible language for anything ever and subjecting yourself to the most critical possible security vulnerabilities for absolutely no reason. There are 5-20 different standards, no program or library states which one it follows. These standards cross object and library boundaries and touch on ABI and all kinds of inter module soykaf, squaring the complexity. All the standards starting from ANSI C are actually abstract machines that will execute your code according to these abstract semantics that nobody reads (i.e, you did this benign looking thing and it is now compiled into a stack smashing vulnerability). The libraries are essentially extension to the language and square that complexity. The language itself has terrible ill defined syntax that will also do what don't think it does, squaring the complexity yet again. The 10 or so similar giant concerns that are piled onto the language for no reason make it n^10 harder to reason about whether the code has stack smashes, than if C was just an assembler or a well defined language.

>>32011 >memory leaks Note that preventing leaked memory *completely* is almost impossible. This is the reason that leaking memory in Rust is actually permitted. It even allows you to leak memory deliberately using `std::mem::forget`. You can read more about this in the Rustonomicon: https://doc.rust-lang.org/nomicon/leaking.html The language solves a lot of memory issues that come up, but not all of them can be solved. >>31483 Here's one more explanation: `unsafe` is a keyword that allows you to write and interact with code that cannot be proven safe (with the definition of the Rust language) by the compiler. The way it's supposed to be used is either 1. writing a safe abstraction using the underlying `unsafe` code that has been audited in some way to be safe (even though *the compiler* cannot prove that it is safe), or 2. exposing an interface that you need to be very careful with if you want to use it because there are things that can go wrong (as is the case with `std::vec::Vec::from_raw_parts`, for instance). Rust isn't perfect, no language is, but it goes a long way in the space of imperative and systems programming language to make it *as safe as possible*.

Vue can be easily integrated into a project, import it using the CDN & use it for binding DOM elements to Js variables. i understand you can bind DOM elements to vars manually but what's the point unless you're trying to learn

Go is the perfect corporate language for mediocre devs. Lisp is uniquely positioned for its developer experience and interactive environment. Erlang seems to be well positioned to do high fault tolerant distributed systems. Rails was a perfect MVC framework for web CRUD. MLs and Haskell-likes are well suited to Programing Language Theory, parsing, meta programming and language developement.

Forth is great for ease of programming extremely low-resource systems.

>>34039 MLs are fairly bad for meta programming, esp if you compare it to a homiconic forth or a lisp, or the works of small talk and it's derivatives. Further i would combat the idea of mls being good for language development, the tools are good for modeling layers but bad for anything in between. If anything lisp is much better positioned for it, i think every major lisp has a feature for exhaustion for closed types and pattern matching (open extensions are needed sometimes, which lisps do well but mls struggle for)

>>31471 The problem with using C for higher-level work is that the stdlib is mostly designed with low-level programming in mind. You're going to end up either spending a ton of time and effort doing tedious unenjoyable grunt work, or using a bunch of other people's libraries, at which point you might as well just use C++

>>31314 * Lua and Chibi Scheme are perfect for embedding them into a program (i.e. using them as a scripting language, like in Awesome WM). * Smalltalk (Squak and Pharo), Common Lisp + SLIME/SLY (or Zmacs or Interlisp) and Factor (which is similar to Forth) have the best environments. * Racket (DrRacket IDE) has the best environment for a beginner programmer. Try it and you will understand. * LaTeX is perfect for writing white papers (especially math/physics). Have you ever tried using the formula editor in M$ Word? It fuarrrking is like kicking dead whales down the beach! And it makes Word even crash sometimes. * Fortran is probably still the best language for numerical calculations. * AWK, Sed and Perl are perfect for text extraction and manipulation. I curious about TXR but I have never used it. * SQL is (still) the best for relational databases. * Scheme/Common Lisp, Smalltalk, Forth/Factor, ML (PolyML), Prolog (SWI-Prolog), assembly and C are great for changing the way you think and for learning new programming concepts. >>32007 >APL How to even learn it? To me it looks as much as write-only language as Brainfuck does. >>34067 I agree. For creating anything that's not low-level or embedded system, I think it's better to use C++ but limiting/choosing the features you use (and ban everything else). But the problem is that how you decide what features you will use. I haven't seen any good answer to this question.