TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: What would be your “perfect” programming language?

41 点作者 hyperswine超过 2 年前
Looking for opinions on what you think are the actual issues with languages. Ive heard toolchains and documentation are a pretty big part. If say, there was a language like rust + go + scala, with an exceptional package manager and documentation, would you feel compelled to try it out?

61 条评论

Sohcahtoa82超过 2 年前
Python, but with static typing and compiled to native code.<p>I love Python&#x27;s syntax. It&#x27;s usage of whitespace forces people to have <i>some</i> semblance of proper formatting. Overall, I find Python code extremely easy to read.<p>But my god is it slow, and I&#x27;ve always assumed a lot of its slowness is due to being interpreted and the duck typing.
评论 #32816164 未加载
评论 #32814808 未加载
评论 #32821270 未加载
kaba0超过 2 年前
‘Growing a Language’ and the ‘Are We There Yet’ presentations changed the way I look at languages, so right now I would say my “perfect” high-level PL would be a Java-like language (possibly running on the JVM due to ecosystem-reuse and the killer GCs and performance) where immutable “objects”&#x2F;values are the first-class citizens, but method implementations can use local, mutable semantics. I would also very much add a ‘pure’ keyword marking side-effectless functions&#x2F;methods.<p>It sort of sounds like Scala though, but I would probably settle for a weaker type system but with constraints (like JML or Clojure’s spec) that are tried to be proven at compile time but will fall-back to be checked at runtime in debug mode (and if marked so, even in prod). Also, would probably make Clojure’s atom&#x2F;ref&#x2F;etc concurrency primitives the “most first-class”, so other than the possibly mutable method implementations, everything would be safe+ concurrency-wise.<p>It is pretty much a mix between Scala and Clojure, or a non-lisp clojure with some types, so not really original..<p>Oh, and Haskell’s target typing for number literals, I honestly don’t understand why don’t we use that <i>everywhere</i>.<p>+ AFAIK, deadlocks can’t be statically guaranteed
评论 #32819945 未加载
评论 #32819887 未加载
alkonaut超过 2 年前
Some middle way between F#&#x2F;Kotlin and Rust. Sum types, generics etc are completely non-negotiable. Something where I can use a GC for 90% and build regions of high perf or low level when needed. I want to say “in this region I want zero allocations” and the compiler will warn if an iterator or closure or something ergonomic-but-expensive allocates in that region. This is where CLR&#x2F;Jvm lands often fail. I even want to be able to get rid of virtual dispatch and all pointer chasing but only for select regions. In some high level languages I can’t tell whether an abstraction comes at a cost.<p>In the bulk of the code I want the syntax to be as terse as possible so the business logic is as clear as possible even if it comes at a perf cost. This is where Rust often fails. The logic of something where I don’t care about perf is obscured by token salad for Box’es and similar.
cm2187超过 2 年前
To me what matters the most isn&#x27;t the language but the ecosystem:<p>- versatility: create desktop apps, mobile apps, websites, CLI<p>- quality of IDE &#x2F; tooling<p>- lots of libraries to deal with all sort of corner problems<p>- lots of knowledge I can google<p>- if used professionally: lots of talents available<p>For the language itself, I only really care about one thing: statically typed, just because it eliminates all sort of silly bugs and makes refactoring and navigating the code so much easier. But I am not dealing with hard computer science problems.<p>But the most important thing is muscle memory: not having to even think of how to solve something, just do it. We can probably adapt to any major language, but you aren&#x27;t productive until you develop muscle memory. That&#x27;s why I am not looking to switch to any shiny new thing unless I have a really compelling reason to do so.
评论 #32808076 未加载
评论 #32808077 未加载
评论 #32844855 未加载
mattnewport超过 2 年前
Syntax like F# but with the ability to get performance like C++. Linear types seem to offer some hope of being able to have manual &#x2F; non GC memory management in a functional programming language but I haven&#x27;t really seen this done in a mature functional language.<p>To really get good performance you probably need the ability to drop down and write more procedural style code in hot code paths and expose it with a functional interface. The details of what exactly that would look like in a way that integrated nicely would be important. I&#x27;d also want to be able to easily move code to the GPU or incrementally vectorize it.<p>I&#x27;d also like to see the one language &#x2F; runtime support everything from C++ constexpr style compile time programming through native compilation, JIT runtime and an interpreted mode for scripting with it being easy to interoperate between levels and reuse the same code across contexts.<p>A good ecosystem of tools and libraries with a sane package manager and build system would also be important. F# is decent there but could still use improvement.<p>I&#x27;d also like to see less impedance mismatch between serialization and runtime data structures and with database &#x2F; relational data. Hoon is pretty interesting in how there is no real distinction between runtime and serialized data in many contexts but its harder to see how to do something like that and meet the other goals above.<p>Much of the above is driven by the needs of games and VR. I&#x27;m interested to see what comes out of Simon Peyton Jones working at Epic as it seems it may lead to something along these lines.
评论 #32808016 未加载
karmakaze超过 2 年前
F# is the closest I&#x27;ve found. A pro&#x2F;con of F# is the .NET ecosystem which has many C#-isms which both accelerate library development and detract from functional styles.<p><pre><code> - functional - type inference (but not so much to slow down compilation) - not too heavy on type abstraction - multi-threaded - local heaps for actors - cross-platform </code></pre> I&#x27;m also disappointed that Pony doesn&#x27;t have as wide adoption as Rust or Zig.
评论 #32839066 未加载
captainmuon超过 2 年前
I would want something like C++&#x2F;Typescript&#x2F;C#&#x2F;Python, but only the good parts.<p>- Multiparadigm, that means traditional OOP, but also first class functions (well first class everything)<p>- Compiles to native code, runs <i>relatively</i> fast<p>- Designed from the ground up for async&#x2F;await<p>- No undefined behavior<p>- Statically typed, but with the feeling that the compiler is helping and not punishing you. I get that feeling from Typescript, Python+MyPy, C++ on a good day, Kotlin.<p>I would also love to experiment with a few ideas of mine:<p>- Voluntary checked exceptions (You mark a block specifically and it is a syntax error if an exception could possibly leak that block).<p>- First class observables for easy GUI binding<p>- You can lift <i>the action</i> of a piece of code into a variable. Then you can reason about this action. For example, you would write imperative looking code to modify a document, and it would generate objects for the &quot;command pattern&quot; so you&#x27;d have undo functionality. Or you could lift a longer running action and have it running on a thread and cancellable. I imagine this to be closures on steroids.
评论 #32808481 未加载
评论 #32808467 未加载
0atman超过 2 年前
Rust with lisp syntax.<p>Like what this macro does <a href="https:&#x2F;&#x2F;github.com&#x2F;JunSuzukiJapan&#x2F;macro-lisp" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;JunSuzukiJapan&#x2F;macro-lisp</a><p>Wait maybe what I want already exists
评论 #32819941 未加载
评论 #32807958 未加载
评论 #32807971 未加载
tomashubelbauer超过 2 年前
TypeScript, but the only supported module system is ESM (including extension being required like it is in the browser), there is no interface and enum (types and type unions are used instead), there are nameof and typeof operators in the language and there is syntax for getting a runtime value representing a type (for example string union into a string array) or even straight up option&#x2F;syntax to selectively (up until absolutely) enforce type shapes at runtime.
评论 #32844837 未加载
alexmingoia超过 2 年前
- One executable that is the runtime, accepting one argument: the source code file.<p>- No linters. Code is auto-formatted.<p>- No modules. Includes can be namespaced&#x2F;aliased.<p>- No package manager. Include by Git URL with tags.<p>- No type annotations. Automatic type-checking.<p>- No user-defined types. A few good types is better.<p>- No null. Set membership with maps is better.<p>- No exceptions.<p>- No loops. List and map comprehensions.<p>- No general recusion. Only tractable transitive closures (ala Datalog).<p>- No higher-order functions.<p>- Terminating. All programs terminate. Turing completeness is not desirable for most domains, but predictable semantics is.<p>- Safe. No undefined behavior. No crashes.<p>- Persistent, the runtime is also the database. The language is the database.<p>I&#x27;m working on a language with exactly this set of features. Email me if you&#x27;re interested.
评论 #32809148 未加载
评论 #32808644 未加载
评论 #32808953 未加载
评论 #32833717 未加载
评论 #32809416 未加载
评论 #32819914 未加载
muzani超过 2 年前
I&#x27;ve actually been having a lot of fun building stuff using OpenAI Codex. I suppose something where I could write the specs and the AI spits out something resembling HTML&#x2F;JS&#x2F;CSS so that I can verify that I communicated correctly.<p><pre><code> - create a dark mode palette for the page based on this image: {file path} - make a form with a single name (not first and last), email, country code, phone -- this form should allow a document upload when clicking -- allow drag and drap to upload documents -- add a tick box that says &quot;I agree with terms and conditions&quot; - this form should have input validation -- all fields should be secure from injection -- name can be anything except number -- file type is documents (not images but including PDF) -- absolutely ban exe files - upon valid input, send this form to {URL} - if the response from {URL} is valid, redirect to {success page} -- else show the error message if it&#x27;s type 200</code></pre>
评论 #32807944 未加载
kryptiskt超过 2 年前
I&#x27;m afraid that a language that was an agglutination of features of those three languages would be horrible to work with. Omitting features that aren&#x27;t pulling their weight is key in making a good language. My instinct is to prefer a language with a minimal and orthogonal feature set. Tastes differ and some languages have a good reputation despite putting in all the bells and whistles (C# goes against all my minimalist impulses in language design, yet I find it very pleasant to work with).<p>Minimalist languages face their own challenges, the Lua mailing list is besieged by people who love the minimalism of it and only want to put in just one little feature that would make it perfect for them. If there wasn&#x27;t a strong filter, it would have hundreds of those little features and not be so minimal anymore.<p>Anyway, tooling is great, but what I want to see most of all is simplicity, and not simplicity in the sense of Go, with masochistic manual error handling and all that imperative boilerplate. I&#x27;d like simplicity like Scheme or SML, omitting what isn&#x27;t needed or can be relegated to a library. With great tooling, of course.<p>So, what I most of all want is for SML to become popular. Which isn&#x27;t going to happen. So all I can do is to argue for replacing C++ with Rust at work (there&#x27;s not much resistance actually, more than finding resources to do the actual work, which is problematic).<p>Anyway, I have fooled around with making my own language, but I don&#x27;t think it&#x27;s a good idea anymore (but damn would it be good if there was a modern SASL, think Scheme with ML syntax[0]). Because you correctly identified that it&#x27;s tooling that is the decider these days. So if you want to make a difference, find an underappreciated language that is close enough to your ideal (there will be several, unless you have really wild ideas) and put in work on tooling for it instead.<p>[0] <a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20150402133901&#x2F;http:&#x2F;&#x2F;www.eis.mdx.ac.uk&#x2F;staffpages&#x2F;dat&#x2F;saslman.pdf" rel="nofollow">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20150402133901&#x2F;http:&#x2F;&#x2F;www.eis.md...</a>
评论 #32811207 未加载
westoque超过 2 年前
Ruby. To quote the creator Yukihiro Matsumoto:<p>&gt; I believe that the purpose of life is, at least in part, to be happy. Based on this belief, Ruby is designed to make programming not only easy but also fun.<p>Writing Ruby code feels natural, from creating classes, all the way to its basic types. Knowing everything is an Object makes it easy to work with.<p>The tooling is amazing as well, from managing gems through bundler, and running simple scripts such as rake tasks.<p>Now, if it&#x27;s performance can be further improved, say like Go-like speeds then it would be further used.
评论 #32844830 未加载
wruza超过 2 年前
The one that would allow a domain specialist to skip all the dev&#x2F;build-ops and wheel-research into a project structure and jump straight into a business logic. Akin to what excel is to users, ignoring its clumsy parts in this analogy.<p>To name a few details:<p>Rich but plain standard library with <i>convenience</i> features. E.g. if you have to read json file, you just readJsonFile(filename), not sys.fs.readFile(fn, “a”, {encoding:”utf-8”}).pipe(new JsonReader({streaming:true}).inPipe()).collect(pipeUtils.buildArray()). If you have a date, it should be easy to modify, format or extract any of its parts, and it must be a built-in standard type. If you work with http, it must be result = http.postJson(data), easily findable in a reference. If you want to just communicate with another instance, it’s result = myInstance.&lt;method&gt;(&lt;args&gt;), not http.<p>Good data extraction, transferring and restructuring features, e.g. var data1 = obj.{name, id, contacts[].value}; obj.{a, b} = data2.<p>Development environment is the same as runtime, no explicit build-deploy phase. See a bug or require a new feature? Click “Menu - Edit module” and edit it right there with live data and live tests. When you save, your temporary db instance&#x2F;transaction&#x2F;backup&#x2F;whatever is applied to the main branch, after it gets its own backup.<p>I have much more bullet points than time rn, so I’ll stop here.<p>This is not exactly a “language”, but that would be perfect.
评论 #32819972 未加载
torstenvl超过 2 年前
C but with the following changes:<p>- Guarantee 8-bit byte and twos complement<p>- No undefined behavior. All behavior is defined even if the ramifications of that behavior are not. Use after free? The data in the memory location is written-to or read-from, not omitted by compiler, and programmer is responsible for the second- and third-order effects thereof. Signed integer overflow? You get the assembly ADD instruction for your platform&#x2F;data width and see what happens.<p>- Fixed width integers. int8_t == short short int. int16_t == short int. int32_t == int. int64_t == long int. int128_t == long long int.<p>- char is by default always unsigned.<p>- byte type similar to unsigned char but requires explicit cast.<p>- Anonymous functions well-supported.<p>- A method keyword inside a struct defines a function pointer to an anonymous function with the signature and definition that follows.<p>- New operator --&gt; such that x--&gt;y(...) is equivalent to y(x, ...) (perhaps with additional error checks)<p>- Arrays no longer degrade to pointers but to fat pointers with an aligned prefix sds-style. Argument syntax for an array&#x2F;fat pointer is arg[..]<p>- char type used alone is deprecated<p>- string type is an array&#x2F;fat pointer of type char[..]<p>- str* functions deprecated; now that unique identifiers can use more than the first six characters, use string* functions instead<p>- &quot;C&quot; locale defined as using UTF-8 normalized to NFC<p>- Conforming change: allowable main() signatures include int main(string argv[..])
评论 #32814439 未加载
评论 #32816590 未加载
cercatrova超过 2 年前
Something that takes PL theory concepts and puts them into practice:<p>- dependent types<p>- algebraic effects<p>- linear types<p>- algebraic data types<p>- higher kinded types<p>- homoiconicity (so it&#x27;d have to be Lisp-like, but typed)<p>- borrow checking, and beyond, such as region borrow checking<p>- cross-platform, JITed, as well as ahead of time compilation in release mode<p>- static metaprogramming
评论 #32844818 未加载
valenterry超过 2 年前
Since I&#x27;m not doing lowlevel stuff, for me it would be a statically typed language that has a typesystem so powerful that it never gets in my way and lets me express all constraints in types that I need for my domain (so it must be a value-dependent typesystem or similiar). In addition, the syntax must be terse so that it&#x27;s easy to define (business) datatypes and mappings easily, so that someone can come in and read those definitions quickly and understand the domain.<p>And then one feature that I like which few languages support are some kind of contexts. Scala does this really well for example, but even in Scala it could be improved.<p>What I mean is that code that looks the same can mean different things in different contexts. The typesystem then ensures that it cannot be used wrongly though.<p>An example would be how &quot;5 ± 3&quot; can mean different things depending on the context, such as &quot;1 or 8&quot; or &quot;mean of 5 with variance of 3&quot; (in statistics).<p>Without such a feature it&#x27;s hard to translate thoughts into code as easy in certain domains.
评论 #32844803 未加载
frou_dh超过 2 年前
Standard ML, but unfrozen and most of the &quot;successorML&quot; proposals integrated into the standard. And it has somehow sprung a large healthy library ecosystem. And the MLton toolchain has gained a REPL.
wheybags超过 2 年前
A C++ dialect that dropped exceptions, headers and backwards compatibility (especially backwards compatibility with plain C). Everything that can be is statically linked, so no fussing about ABI. Explicitly no support for dynamically linking the std lib, or passing std lib objects across ABI barriers. One big build in a compiler that runs as a daemon, no messing about with recompiling the world in each translation unit. One implementation that works the same everywhere because it&#x27;s the same code. No committee, no standard. The implementation is the standard and there can be only one.<p>Have thought about this a lot, I really want it. I even started messing around with implementing it, but it&#x27;s just a toy (an abandoned toy, even) for now.
undefinedzero超过 2 年前
TypeScript without the BC shit (and a native JIT compiler). Basically I wish for a TypeScript that’s maintained like Swift where the primary goal of the latest version of the language is for it to be the best possible language ever.
评论 #32815751 未加载
JonChesterfield超过 2 年前
I want to write a program that has no mention of concurrency and runs efficiently on clusters anyway. So no threads, fibres, processes, actors, atomic, mutex, channels, queues, coroutines. Not in the language nor in a library.<p>Push the concurrency and distribution machinery into the language runtime. Developer can neither see nor influence it. Program just runs faster when put on more parallel hardware.<p>The price appears to be dropping mutation, severely limiting I&#x2F;O and coming up with a domain independent scheduler for the runtime. So it&#x27;s expensive but not impossible.
评论 #32808501 未加载
评论 #32809451 未加载
评论 #32808044 未加载
评论 #32819547 未加载
jokoon超过 2 年前
C++ without the old bad things it carries for the sake of backwards compatibility.<p>Maybe a simpler subset of the language with it&#x27;s most common usage, like STL containers, string, etc.<p>And a similar syntax, I don&#x27;t want want exotic things like in rust.<p>By the way I wonder why it&#x27;s not possible to deprecate things in C++, and compile different part of a code base with either an old or a new part of the language. C++ really needs to break off backward compatibility.
评论 #32821936 未加载
trinovantes超过 2 年前
Typescript without the CJS&#x2F;ESM&#x2F;tooling BS. Plus a JIT compiler for performance.
评论 #32807967 未加载
评论 #32814676 未加载
zzo38computer超过 2 年前
Similar features of C probably, but with many differences (and probably different syntax too). Specifically, I would want to have such things as:<p>- Good documentation.<p>- Always twos complement. (For one thing I would have -fwrapv being the default setting.)<p>- Reduce some undefined behaviour, so that more of the behaviour is defined or partially defined.<p>- Types specifying how many bits, or can specify in terms of other features (e.g. pointer size).<p>- Not Unicode.<p>- Avoid the confusing syntax for types that C has.<p>- The C comment syntax has &#x2F;* even though &#x2F; followed by * would be a valid sequence in C, so, such a conflict should be avoided in a better programming language.<p>- Parameterized types.<p>- Must still have the goto command.<p>- More powerful macros and preprocessing (including auto-generation files too), including a superset of the capabilities of C, but with possibility of hygienic macros, too.<p>- Better namespacing possibility than C.<p>- Does not need too many extra libraries than C, and can be used with any libraries for C programs (including possibility to be called from C codes, too).<p>- Many of the GNU C features.<p>- Associated data with types (which may include functions, constants, numbers, strings, other types, etc).<p>- You can still use pointer arithmetic, etc like is also possible with C.<p>- String type being the length and pointer to beginning of data; this way you can easily make slices. For compatibility with C codes, they will by default also always having the null terminator after the data, too.<p>- A few additional things, too.
creakingstairs超过 2 年前
Strongly typed Elixir would be it. Even better if it can be gradually typed like Typescript.<p>Jose announced that they are working on it but I can’t wait :p
评论 #32814016 未加载
mikewarot超过 2 年前
I&#x27;d start with most of the best parts of Delphi&#x2F;Free Pascal<p>Insanely fast recursive descent single pass compilation.<p>Assignment and equality test have different tokens := vs =<p>Var parameters instead of messing with pointers<p>Functions return values, procedures don&#x27;t<p>Strings that are automatically reference counted (no allocation or garbage collection to worry about), counted (so you always know how many bytes of text you have), and just work, yet can hold at least a gigabyte<p>Units for separate compilation<p>Strong typing<p>Then I&#x27;d add some things from elsewhere<p>pre and post increment&#x2F;decrement from C<p>declarative programming, using a &quot;magical assignment operator&quot; &lt;&lt;==&lt;&lt; or something like that to indicate that the left is always made to equal the expression on the right, and updated any time the expression changes. -- from an experiment called Metamine that was here a few years ago
评论 #32834950 未加载
t43562超过 2 年前
Firstly it would be persistent - so you&#x27;d never need to write SQL or file handling code again. Want to save a map or list or object of some kind? Just reference it from the root object (can be indirectly) and it is magically there the next time you start your program.<p>Secondly, it would be as easy to program in as Python but have some way to be more efficient when that was strictly necessary. Might be JIT or the ability to embed a lower level language or some kind of type hints that made it more efficient or who knows. One wouldn&#x27;t need to spend too much time on crap like &quot;build systems&quot; or package management or whatever to make it work.<p>Thirdly: It would work very well with concurrent&#x2F;asynchronous situations and have powerful abstractions for them like channels, continuations etc that would make them as simple as they could be.
评论 #32808724 未加载
yrgulation超过 2 年前
I know this is not pertinent to your question, but i would like to see DLang gain more traction.
qsort超过 2 年前
Very abstract question, but the code is compiling, I&#x27;ll bite right in.<p>I think the &#x27;ingredients&#x27; for my ideal language are more or less the following, in decreasing order of importance:<p>- Quality of the ecosystem. You can&#x27;t buy or engineer this, it kind of has to happen naturally. Good FFI and trying not to be a &quot;let&#x27;s rewrite the world&quot; language help immensely. It&#x27;s controversial to put this as the most important bullet point, but the world we have to program in is much more complicated than it was even just 20 years ago. Programs live in an environment and have to interact with databases, networks, etc. I just don&#x27;t see myself programming in a language where I have to rewrite my own data structures or network code or postgres integration, it&#x27;s way too much work for way too little gain.<p>- Tooling. Just look at Java and Go (also Python and JS, albeit to a lesser extent). It&#x27;s a massive, massive productivity gain to have modern, effective tooling that supports modern workflows.<p>- Language features. I&#x27;m partial to the ML family, but I&#x27;m not a radical in this respect, I&#x27;ll program in almost anything as long as it&#x27;s sufficiently expressive and doesn&#x27;t have insane semantics.<p>A few _very wild_ ideas:<p>- A configurable type system. I&#x27;m sold that stronger and more articulate type systems are the future, but sometimes, especially in smaller projects, it&#x27;s incredibly annoying to have to prove to the compiler that the code you wrote is actually allowed. There&#x27;s an inherent expressivity vs. correctness tradeoff that it would be interesting to have &quot;different settings&quot; for.<p>- A dependency system based on functional semantics rather than names. Imagine to reduce each function to a canonical representation (for example: its De Brujin encoding). Now you can design a dependency system where you can import a function based on its representation rather than its name.<p>- First-class algebras. Imagine being able to program user-defined structured sets. Strings as monoids, Vec3 as vector spaces, calendar as affine spaces, etc.
评论 #32844779 未加载
kjeetgill超过 2 年前
Pretty much just Java but a few more affordances for flat memory layouts. I know value types are in the works and the new memory api is in preview so we&#x27;re getting there.<p>Oh, and I think every language should come with an AST parser in python. We need to really lower the barrier to manipulating codebases with code. And before any one mentions Lisp, we know — and we&#x27;ll never learn. Blub blub blub.<p>I&#x27;d like to be able to @Annotate a class with @Localized and enforce just that it&#x27;ll never get assigned to a field or passed to public functions — only local variables and private functions. For anything mutable, it&#x27;ll buy you 80% of what a borrower checker would.
AnimalMuppet超过 2 年前
There is no perfect answer, or at least no universal answer, and there never will be.<p>The perfect programming language fits the way I think. But other people think differently, so my perfect language won&#x27;t be perfect for them, and vice versa. There is no answer that is perfect for everyone. There can&#x27;t be.<p>The perfect programming language would handle all the incidental complexity of the problem I&#x27;m trying to solve. But different people are trying to solve different problems, and what is incidental complexity to me is essential to someone else. Again, there cannot be a perfect answer.<p>We can get <i>better</i>, but we can&#x27;t get <i>perfect</i>.
perceptronas超过 2 年前
In my opinion, Rust is what Scala would be if ownership was flagship feature and everything was built around that. Certain combinations just don&#x27;t match.<p>Let&#x27;s take an example of Scala. Great language for most business domain problems: easy to write expressive, bug-free and concurrent code. What enables those strengths also enables its weaknesses: steep learning curve, a lot of ways to reduce boilerplate which increase complexity of codebase, powerful type-system to prevent bugs&#x2F;invalid states - you have to deal with &quot;type gymnastics&quot; and slower compilation times
评论 #32814257 未加载
prachisingh123超过 2 年前
I m a frontend Developer, So for me React and JavaScript is the perfect programming language. JavaScript makes it easy to develop a responsive design. JavaScript has become integral part of Internet experience because it increased interaction and complexity in website or application. It would not be possible to have responsive website, Content management systems, social media, Mobile friendly ad SEO friendly website&#x2F;application with JS.
评论 #32834937 未加载
epgui超过 2 年前
A haskell-like proof language (dependent types?) with lisp syntax.
评论 #32814032 未加载
rramadass超过 2 年前
* Seamless integration&#x2F;interfacing to C&#x2F;C++ libs&#x2F;toolchains&#x2F;etc. and ecosystems.<p>* C&#x2F;C++ core made more multi-paradigm in the spirit of Mozart&#x2F;Oz.<p>* The runtime semantics of Erlang and BEAM VM.<p>So it would be a set of DSLs (one per paradigm but the ability to work together) with a common core of modified C&#x2F;C++ like syntax and the ability to run on top Erlang BEAM VM with its guarantees. I think it is fully doable today and <i>will</i> eat the World.
xboxnolifes超过 2 年前
* Strongly, statically typed.<p>* Good package management.<p>* Good, easy to reason about build system.<p>* Popular enough to find jobs with it.<p>Probably a lot more, but I don&#x27;t really remember my annoyances unless they&#x27;re in front of me.
评论 #32808353 未加载
mariusor超过 2 年前
I like some of the options found in the latest generation of programming languages (Jai, Odin, Zig, etc).<p>1. Compile time execution which opens the way for invaluable tooling that can be built&#x2F;used directly.<p>2. Memory allocation strategy as a global&#x2F;context functionality. Strong correlation between data structure layout and resulting memory layout.<p>3. Strong meta-programming&#x2F;introspection focus.<p>4. Ease of compilation, ease of creating static binaries.
NWoodsman超过 2 年前
I was going to say &quot;a better version of C#&quot; but maybe an entirely different language would be better.<p>C# uses stack and heap for memory management, which is to say this is an entire language designed around memory management. Should memory management be a core of a modern programming language? Available memory has expanded like 1000x in the lifetime of this language.
评论 #32816261 未加载
mtlmtlmtlmtl超过 2 年前
Rust with Lisp syntax so I could actually write unhygienic macros without learning a bunch of arcane stuff about compiler internals.
评论 #32807931 未加载
horsh1超过 2 年前
Fixity and associativity control at least at the haskell level. Notation comparable to Coq level. Generics without jvm limitations. Subtyping or subsets of inductive types. Rich signature overloading. No need for general recursion, loops etc. Pretty printing out of the box. Static literals (from the binary directly to memory).
ergeysay超过 2 年前
Good question! From the top of my head: non-opionated memory management, nice syntax (and meta-semantics), strongly statically typed, &quot;interpreted with possibility of AOT compilation&quot; execution model and easy and performant native interop. Let me expand the points in order.<p>Non-opionated memory management means that I am in the ultimate control of each allocation it does. Even if it requires GC it should allow me to redefine malloc&#x2F;free and sandbox it into a memory region I choose (like Lua). It should not allocate memory willy-nilly and free it as it chooses, especially if it aims for a &quot;system language&quot; role.<p>Nice syntax is the most opionated point of mine. It should definitely be C-like and not, for example, Python-like or Lisp-like. After all, everyone can read JavaScript. I like the idea of expanding C syntax with first-class blocks (like Ruby) and semantic macros and quoting like Lisp. C has a tradition to make language constructs first-class - that was the motivation for varargs, but it&#x27;s ability to create new language constructs is flawed. You can #define a &quot;foreach&quot; with &quot;for&quot;-like syntax, but it still falls short compared to what proper semantic macros can achieve. It would be nice to be able to define a &quot;foreach&quot; as a hygienic macro with a quote.<p>Typing is a non-question - I don&#x27;t want to have to deal with dynamically-typed languages anymore. Extra points for local type inference. Strong static typing also enables a lot of performance enhancements down the line.<p>The execution model is the next salient point. My perfect language should have REPL (I&#x27;m that spoiled by Ruby and RoR) and also should be performant enough in release&#x2F;production builds. Which is why it should allow both live coding and ultra-optimized AOT builds right down to native machine code. In my opinion, the best way of AOT compilation is targeting C or C++ - the AOT compiler shouldn&#x27;t have to implement any optimizations Clang or GCC already have. Maybe it could target LLVM IR instead.<p>Native interop should be zero-cost and ideally based on LLVM tooling. The performance cost of calling a C or C++ function should be negligible. Regarding the tooling, I don&#x27;t actually want to write FFI interfacing code by hand, it can easily be generated automatically.<p>The only language I know of that actually ticks most of these boxes is daScript, but it is still in the early phase of development and I don&#x27;t particularly like the syntax of it.
评论 #32844782 未加载
ivmoreau超过 2 年前
Dependent Haskell. Maybe one day.<p>But also a better package system than the current state of Hackage. Otherwise, Haskell is perfect.
therein超过 2 年前
I just want something that will allow me to have what FlatAssembler does but in something higher level like C. I just want a flat binary, only to use the stack, no relocations, no data, rdata etc. Strings on the stack or heap.<p>Been trying to hack Zig a little bit to get what I want but still needs some post-processing.<p>Anything comes to mind?
spion超过 2 年前
Rust with a GC (and therefore without borrow checking). I&#x27;ll copy the stuff I wrote on a twitter thread recently below:<p>Rust&#x27;s borrow checker is the most innovative but also most inconvenient bit, and GCs are certainly more convenient.<p>But Rust is much more than that:<p>- Rust traits are like typeclasses, but you can still use dot notation for better discoverability, which IMO makes them even beter (no, hoogle is no substitute for automatic, instant inline editor documentation).<p>- Macros in Rust are very powerful: not only can you control what they generate, but you can also control error messages via `compile_error!` and the exciting upcoming compiler diagnostic API. This means great DX is possible, even when macros are used!<p>- Rust lets you write code that uses Result&lt;T, Err&gt; that is almost as compact as exceptions in other languages. The `?` (previously try! macro) operator implicitly early-returns if there is an error. With a bit of effort, its usable even in functions such as `map` and `flat_map` via `collect`<p><pre><code> - Traits are really helpful here in two ways: You can implement `From` for standard error types to ensure they&#x27;re converted to your error type (Or you can use an awesome ready-made crate that lets you add context such as https:&#x2F;&#x2F;docs.rs&#x2F;anyhow&#x2F;latest&#x2F;anyhow&#x2F;). Traits also help .collect() work with Result regardless of whether the iterable is an iterator, vector or some other data structure. </code></pre> - rust-analyzer and how well it works in vscode.<p>- Cargo, the Rust package manager, just works. No fuss. If you want to setup a monorepo of multiple crates, binaries, libraries, no problem - it can do that too and it will know how to handle it. Contrast with JS&#x2F;TypeScript ecosystem, where monorepo setup is the topic of blogposts.<p>- Rust documentation culture is crazy good. Crates go as far to add a copy-pastable example to many of the functions. Thanks to python style doctests, those examples are also automatically tested. Almost all crates have an excellent &quot;README&quot; page that introduces the library properly. Contrast with Haskell where there&#x27;s none of that.<p>- Some things available are just plain cool. For example, just add the Rayon crate <a href="https:&#x2F;&#x2F;docs.rs&#x2F;rayon&#x2F;1.5.3&#x2F;rayon&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.rs&#x2F;rayon&#x2F;1.5.3&#x2F;rayon&#x2F;</a> to your project and replace a few key `iter()`s with `par_iter()` and you have a multi-core program that is 4-8 times faster on your average machine.<p>- One of my favorite macro packages is peg (<a href="https:&#x2F;&#x2F;docs.rs&#x2F;peg&#x2F;latest&#x2F;peg&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.rs&#x2F;peg&#x2F;latest&#x2F;peg&#x2F;</a>) - it uses the compiler_error api to tell you if you&#x27;ve written a left-recursive definition (not good for PEG). Its super easy to use and as is Rust tradition, produces excellent parse errors with locations.<p>- All those C library bindings available. Enough said.<p>- Its really cool and convenient that you can produce a single binary. Thanks to rust-embed (<a href="https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;rust-embed" rel="nofollow">https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;rust-embed</a>) its also really easy to keep it a single binary in many situations.<p>- Last but not least, the community goes above and beyond to make people feel welcome.
评论 #32814135 未加载
cabirum超过 2 年前
A universally perfect language can&#x27;t exist.<p>There are general purpose languages (say, java, go, rust, ts, and c -- one is better than another for specific tasks), and then there are HDLs, DSLs, constraint and SAT solvers, and many more I don&#x27;t even know about.
haakonhr超过 2 年前
It would probably be a language with Python&#x27;s ecosystem, a development experience like SLY provides for Common Lisp with the syntactic simplicity and elegance of Scheme&#x2F;Racket that makes it so easy to create your own DSLs.
评论 #32947823 未加载
Ygg2超过 2 年前
Rust that solved the async and abstracting over keywords&#x2F;reference types.<p>So future Rust.
dividuum超过 2 年前
Aside from what&#x27;s mentioned already: Longevity. Nothing is more frustrating than being forced to go through already working code just because some version update changed the syntax&#x2F;semantic.
评论 #32809495 未加载
UK-Al05超过 2 年前
Something like standard ML modernised, with a decent ecosystem.
pacifika超过 2 年前
Python syntax and libraries with nim’s packaging and distribution
评论 #32807934 未加载
ohCh6zos超过 2 年前
It would look very close to Kotlin crossed with elixir.
girishso超过 2 年前
I would be all in Clojure if it had compile time type checking, something like Elm.
评论 #32821931 未加载
rco8786超过 2 年前
Ruby with python style type hints
评论 #32807915 未加载
评论 #32807960 未加载
jstx1超过 2 年前
Go without the garbage collector.
评论 #32808148 未加载
评论 #32807935 未加载
eternalban超过 2 年前
I like to answer your post title and brainstorm at a bit higher plane (but it will have implications for the things, such as toolchains, that you highlighted).<p>The germinating thought was remembering the frustration of having to choose between <i>abstraction</i> and <i>performance</i>. Sure, there are languages out there that do address this generally mutually exclusive <i>dual</i> to some degree of success. But there are other duals out there: {<i>semantic-clarity</i> and <i>concision</i>}, and, {<i>effectiveness</i>, and <i>cognitive-load</i>}. And the existing solutions to the first dual generally don&#x27;t do so well, imho, in the other dimensions.<p>So my &quot;perfect&quot; programming language would have to:<p>- allow the programmer (henceforth me) effective abstraction capabilities, in the sense of <i>what</i> the language is used to define and describe, while also allowing for practical high performance implementation.<p>- have excellent semantic-clarity so the poor me who has to read code more than writing it gets a break. But who wants to read <i>War and Peace</i> to understand how a subsystem works? Not me.<p>- be effective. Get things done, and have the above two qualities. But I&#x27;d rather not have to carry some monsterous mental model in my head. That can hurt. &#x2F;g<p>So how do we get there?<p>We already know a lot about tricks to make abstract code fast. So a ~near possibility that I foresee is either teaming up with, or borrowing the knowledge and tool base of, cognitive sciences to get a handle on things like semantic-clarity and cognitive-load. PLT designers will need to -start measuring things-. At some point we need to start measuring cognitive load of languages as we design them, and to do that we also need a bit of help from AI (D&#x2F;ML) (&quot;cheating&quot;, &quot;not art&quot;, &quot;not computer science&quot;? :) so this feedback loop can be hugely sped up.<p>So first we need to have measures, actual physical measurements of a sample of end users, with existing languages and tools, up to operating and debugging software systems. At this point we&#x27;ll have numbers to for example compare the cognitive load of Rust vs Go. Stuff like that. We feed that data to our DL model. That model then is expected to furnish what it thinks of your shiny new language. At that point, the PLT designer first defines the characteristic measures (of those duals), and possibly let say start from an existing language, and then have our friend AI go at it.<p>What will they look like? Hopefully we live long enough to see.<p>p.s.<p>fair to say to get this off the ground (measuring and creating the model) requires DARPA level research effort.
评论 #32844796 未加载
aristofun超过 2 年前
Good language == simple language.<p>So scala and rust are off the table.<p>The best language from devx perspective so far is typescript.
dudeofx超过 2 年前
a language thats best allows me to express my thoughts into code
ruslan超过 2 年前
C.
评论 #32833319 未加载
aprdm超过 2 年前
Python
jjgreen超过 2 年前
Ruby + POSIX threads
OhNoNotAgain_99超过 2 年前
&#x2F;&#x2F; comments would be my perfect language, write good documentation And leave the coding mostly over to CoPilot, or another AI. Although one needs to understand coding, we should work at a higher level. If you cannot write a good CoPilot prompt, i wouldn&#x27;t accept you as colleague, if you cannot describe code your unable to properly write your own thoughts, makes you a team disaster. The language itself thus becomes less relevant these days, and the years to come.
评论 #32808111 未加载