/prog/ - Programming

>>591
Take Rust.
Then bring it to 1.0.

Let that settle for a year or so.
Then let 2.0 hit.


I want that.

My own Right Thing Scheme. It'd have the best module/library system ever created.

>>612
That with Python syntax.

Ruby but with all the Python third party libraries.

Explained it here:
>>>/tech/14976
I feel like progress in the traditional directions is going too slowly, so I'll try a new one. Sure, if you follow LtU, you'll see that software verification and formalization of everything are making great progress, but that doesn't help me express myself better.
A language is a way of thinking, so what would be more obvious than using a structure suited better to thought than spoken language or serializations of it?

>>664
I sort of agree. Text-based communication is overrated.

I want everything to be an API.

>>667
Fuck APIs.

If you meet people from Japan, do they hand out a manual titled "How talk with Japanese people"? Of course not, people can learn from each other and adapt to one others customs. We try to find some common ground and work our way up from there.

We should build computer systems that way, too. It would be a vast improvement over current best practises for interoperability.

Instead, we've been piling up layers of protocols that end up being insufficient at some point yet we can no longer get rid of them lest anything breaks.

But if I grammar change sudden randomly/ still read you can;

>>669
Better than deciding upon some arbitrary protocol like textual communication and then having everyone parse shit.

>But if I grammar change sudden randomly/ still read you can;

wtf

>>664
What sort of progress do you wish traditional languages would make?

>>671
His point is that even though the sentence is mangled you can still read (parse) it.

>>674
> What sort of progress do you wish traditional languages would make?
If I knew I'd use traditional languages.

>>669
See, I take the opposite approach.

I agree that flexibility in protocols is nice, but at the end of the day, protocols and APIs are still necessary.

An API is a contract between the service provider and the consumer. If something fucks up, the API determines who's responsible for fixing it.

Indeed, protocols are a big investment that we'll be stuck with for awhile. The solution is to put a lot of effort into designing the protocols. Make them flexible and provide support for future upgrades.

I also like strict grammars. I don't like sifting through my code for hours, only to find out that the language was interpreting my code slightly differently than I expected. If the language and I have a well defined, mutual understanding, then I have fewer problems.

>>689
This goes against the robustness principle of "be liberal in what you accept, be strict in what you send". HTTP would not be a thing today if it didn't do just that.

Moreover, if you go back 10 years, large software companies and standards bodies were trying to come up with standards to create more interoperable systems such that there would be no endless compatibility hell. They called it SOA* and wound up creating a new kind of hell that's worse than WS-Deathstar. However, the basic premise is sound and still worth exploring further. But it requires higher level, out of the box thinking. I'm sure we'll get there over time, so as long as we don't turn the current practises into a dogma and perpetuate them across generations to come.

*: http://en.wikipedia.org/wiki/Service-oriented_architecture

Something with lots of "->" and [] brackets. That seems to be in fashion nowadays.

>>591
I am making a language.

Personally, I think there's too much emphasis on conciseness and I've never been really happy with mainstream languages (or more obscure ones that I've tried).

People are obsessed with what's the most straightforward "Hello, World" and how little code it takes to perform a specific task. That's just not how software works. The thing I care most about is intent. The ability to express intent.

I think modern languages are sorely lacking in this respect/department. As a very simple example, consider your average C-style language (a syntax style that I love) and shitty Allman-style braces:

while (condition);
{
    // code
}

What is the intent here? Is it to have a while condition that does nothing and an arbitrary scope of code? Is it a simple typo?

while (condition) ;
{
    // code
}

What about now? Does that change the intent? On a token level, it's clearly the same. But that space might mean that it's intentional or it might still be a simple typo.

So I've been making language design decisions based on the notion of intent. All scopes must have braces. There's no such thing as an arbitrary scope, you prefix an "arbitrary" scope with the scope keyword. There's no such thing as a line consisting of just a semicolon. If you intend no operation, there's a keyword to specify that intent. I've been really pleased with the interactions between features that have risen as a result of these decisions.

I think I'm going to hit a niche that doesn't exist right now (although since it's just me and I have a day job, it's probably going to be a couple years before there's any meaningful usage). But that's the type of language that I would (and am) making.

>>690
>be liberal in what you accept

Wow, fuck off with that cancerous bullshit. That silly mentality is what prevented the web from being actually standardized until very recently.

>>703
You mean the same standards that made HTML parsers more liberal in what they accept? Kek.

>>702
Is it dynamically typed?

>>707
Warning: Sperg out ahead. Short answer: Yes, for now.

Long answer:
For now it is and there's really not a lot that you can actually do in it. It currently supports functions and the typical control structures. It targets .NET, mostly so I wouldn't have to worry much about a large number of details that I will have to care about when I go to target native. Also because CCI is a thing that takes care of the IL generation and it's pretty decent. I'm not sure if I'll keep the ability to target .NET or not, probably not. I wanted to focus on development of the syntax and ideas first to prove my concept to myself.

I want static, mostly explicit types, but I'm going to have to bootstrap a type system first. I think types are a natural way to express intent and a very good thing in general.

I'm interested in ideas from Haskell, Rust, and Scala (although I think I'm going to provide "typical" OOP capability as well because it's really hard to emulate some properties of inheritance using a more robust concept). I'm also interested in ideas from Erlang, Go, C#, and curiously enough, C++. That's not to say that it's going to be a mishmash of all of those things, but I think it's better to provide the programmer with the tools to specify their intent appropriately for the situation at hand and also provide the building blocks for when those situations break down so the programmer can compose their own solutions. I hope to provide some value in API design as well as language design and I have some ideas there. Kind of a long-winded answer, I'll throw a sperg warning at the top.

honestly, i'd take anything that was kind of like C but with nested functions and good macro support. like, Common Lisp kind of macro support.

from a quick glance rust is the closest language to this at the moment, but so far I've been too lazy to look that closely at it

>>708
I think dynamic languages are better because the more you let the computer handle for you the better.

>>711
I'm fine with the opinion that dynamic is better, but your reasoning doesn't make sense.

Couldn't a static type system be interpreted as the computer handling a large class of errors for you?

>>712
No, it creates more work for the programmer. Especially when you later discover that algorithms can be made generic across types and you introduce generics into the language. As Erik Meijer once said, in a Java shop you'll find pieces of brain plastered all over the ceiling from the use of generics.

Moreover, using a statically typed language doesn't free you from having to write unit tests. If your language has null or void, you still need to do null checking.

The way I see it is as a logical next step in programming. Do you still use binary? No? How about assembly? Still no? How about a higher level language? Now we're getting somewhere, right? At every step of the way, people who were already doing programming thought their way was the superior way of programming. Those new to programming saw the advantages of assemblers and compilers and did not have to "unlearn" the way they wrote code. You probably learned how to write code in a statically typed language. Clearly when programmers are writing code they
re supposed to declare the type of everything. Truth is, you need to communicate the type with the computer much more often than than to other programmers. Letting the computer figure it out doesn't waste precious CPU cycles, it's not 1954. Yet it frees you from a lot of unnecessary typing in the literal sense of the word. Just like assembly language did for binary and higher level languages did for assembly.

All of the research and development in programming is aimed at making the programmers job easier. Except for brainfuck and its derivatives, of course.

>>720
>No, it creates more work for the programmer.
This doesn't actually address my question. If I take your basic assumptions as true, the answer should be either "Yes, but it also creates more work for the programmer," or "No, it can't be interpreted that way."

>At every step of the way, people who were already doing programming thought their way was the superior way of programming.
I find this notion somewhat funny, especially because perhaps one of the earliest high level languages that had garbage collection, dynamic typing, etc. was LISP (nowadays called Common Lisp).

>You probably learned how to write code in a statically typed language.
You don't know anything about me. For what it's worth, I learned the basics in a dynamically typed "language" (if I can call it that) in junior high school. I also regularly write in JavaScript, Lua, and Python.

>Truth is, you need to communicate the type with the computer much more often than than to other programmers.
What's the evidence for this? It's not even clear that "communicate the type to the computer" is meaningful in the context of your argument.

>Letting the computer figure it out doesn't waste precious CPU cycles, it's not 1954.
Yes it does, but even ignoring that, it wastes human time as well. Type errors are very frequent for me (actually, the vast bulk of my errors in the aforementioned languages are type errors).

>Yet it frees you from a lot of unnecessary typing in the literal sense of the word.
This is still unrelated to my question, and it's a false dichotomy anyway. Hindley-Milner type systems like Haskell are completely statically typed but still almost always inferred, meaning the cost of static typing is precisely 0 above dynamic typing in terms of keystrokes.

But that's not the point anyway - I'm asking why you can interpret typing less as the computer handling more but not interpret encountering fewer errors at runtime as the computer handling more. It would seem to me logically disingenuous to suggest as much regardless of my feelings on type systems.

>>720
Couple scattered points that I realized I hadn't commented on.

>Just like assembly language did for binary and higher level languages did for assembly.
Binary was incomprehensible to the average person, so naturally it would be subsumed. Assembly language required the human to basically be a computer in order to comprehend it, so naturally it would be subsumed.

Explicit static typing is not the same degree of change. To compare them even as stages of evolution is disingenuous.

This also actually gets into the territory of one of my original postulations; that people overvalue terseness and saving keystrokes for what I see as diminishing returns.

>Moreover, using a statically typed language doesn't free you from having to write unit tests.
Nobody said it did. It would seem that you're arguing that because it doesn't take care of all unit tests, it isn't worthwhile on that front. I find this argument lacking in substance.

>If your language has null or void, you still need to do null checking.
And I think a lack of explicit null tagging within the type system is a pox on modern software development. The fact that anything could be any type means that dynamic typing requires you to do the same types of checks, thereby nullifying it as any kind of useful argumentation point.

>As Erik Meijer once said, in a Java shop you'll find pieces of brain plastered all over the ceiling from the use of generics.
And do you understand the context under which he said this? I don't follow his work super closely (although I find many of his ideas interesting), but my off the cuff guess would be that he's referring to how braindead generics in Java are as opposed to the fact that you could just have a dynamic type system. It would be a misquote if he wasn't arguing in favor of your point. He also writes frequently in Scala and Haskell, so this would seem consistent with the notion of Java's generics being braindead. If I have the context incorrect, I would like to know.

>>706
I mean the standards who made it necessary for you to target specific browsers you fuck

add the swap keyword

>>941
In Python:

(a,b) = (b,a)

>>949
Why do you have redundant brackets on both sides of that expression

>>950
To emphasize the nature of the expression. Beginners learn it that way so they don't think it's
>a, (b = b), a
which doesn't mean anything ofcourse

Probably recreate haskell or lisp :P

>>689
Text based communication is far superior to API's.

First of all, with an API, what language can use it? What ABI will it use? Will it support multiple operating systems?

Text based: You don't have to worry about ABI's, everything is UTF-8. Every OS supports UTF-8. Maybe not every os supports it to the extent plan9 does, but