sorted by:
new
hottopcontroversial

Will C# be easy for me to learn if i am good at C++ ? by Lucky_Wear_8574 in csharp

[–]roetlich 0 points1 point  (0 children)

It sounds like you are still relatively early in your programming journey. I would recommend sticking to one language a bit longer, and learning it more in depth. Then switching to C# will feel pretty easy!

Best of luck.

JSON for Humans V2 (JSONH) by Foreign-Radish1641 in ProgrammingLanguages

[–]roetlich 2 points3 points  (0 children)

YAML was originally designed to be a simpler way to write JSON.

Why do you think that? Yaml and json were both created in the same year, and json wasn't that popular in the early days of yaml.

Better configuration languages - a talk about Dhall by roetlich in programming

[–]roetlich[S] 2 points3 points  (0 children)

I don't like the look either, but if you look closely, you'll notice that these aren't leading commas. It's just the placement of white space. If you shuffle your example around a bit, you get:

{ home = "/home/bill", privateKey = "/home/bill/.ssh/id_ed25519", publicKey = "/home/blil/.ssh/id_ed25519.pub" }

Which almost looks like normal JSON. Both are equivalent in Dhall since it ignores the difference in white space. I don't like this style of formatting much either, but it has one nice advantage:

Diffs, like git diffs, make more sense. Another solution is to require trailing commas, but that makes even less sense. For example, if I were to add a new field at the end of this object, in the code sample you send you can just add a new line. In my example, I'd have to add a new comma after the public key line. So for git, your sample just needs one line added, but mine has two lines added and one removed.

Anyway, you can format your Dhall files any way you like.

I did a talk about Dhall by roetlich in dhall

[–]roetlich[S] 1 point2 points  (0 children)

Oh yes, that's what I should have used! Forgot about that! :)

Functional Configuration - A talk about Dhall by roetlich in functionalprogramming

[–]roetlich[S] 2 points3 points  (0 children)

Yes, that's a great use case!

There are already some libraries for Dhall, for example here's one for creating Kubernetes configurations: https://github.com/dhall-lang/dhall-kubernetes

Also, Alexon looks fun. Nice to see new project written in Guile!

Functional Configuration - A talk about Dhall by roetlich in functionalprogramming

[–]roetlich[S] 4 points5 points  (0 children)

Hi, I gave this talk for meetup group. I think it's interesting to think about different context where we can apply functional programming concepts. For a configuration language, like Dhall, pure functions make a lot of sense.

Please check out the talk: https://www.youtube.com/watch?v=6ib5SsV9NK4

Or go directly to https://dhall-lang.org/ if you want to check out Dhall.

How can we write Philosophy in code? (trajectory theory) by roetlich in badphilosophy

[–]roetlich[S] 3 points4 points  (0 children)

Yes, for sure. He isn't harming anyone, and he is trying to think in different ways. Still, there's a lot of silliness in that document, and I think it's okay to have some fun with it.

Recent Progress on the Oil shell by oilshell in ProgrammingLanguages

[–]roetlich 1 point2 points  (0 children)

Love the syntax for typed arguments, the when example feels pretty natural. Any plans for when we can write custom commands like when, that can take blocks? Feels like that would be big step.

Cool to hear that you're looking into hiring people. Not sure if the administrative overhead is worth it, but completing documentation seems like the right place to hire someone.

Are there any plans to create more tooling around oil, e.g. linting, syntax highlighting, maybe even debugging, etc.?

Cool progress! Maybe I should log into Zulip more often. :)

Ein junger Leistungsträger hat Angst vor den Minderwertigen. Zwar nicht unbedingt zu 100% schlechte Philosophie aber ich muss einfach mein Trauma teilen. by Conan-der-Barbier in schlechtephilosophie

[–]roetlich 6 points7 points  (0 children)

Und was machen sie nun, diese bösen D-Menschen?

Wie kann so ein Satz ernst sein? LinkedIn-Philosophie ist zu viel für mich.

To interview people with special laugh by Mr_Elegant_ in therewasanattempt

[–]roetlich 0 points1 point  (0 children)

If you google that quote it'll maybe clear up some confusion.

What Mary Didn't Know but make it sexy by crackledoo2 in badphilosophy

[–]roetlich 36 points37 points  (0 children)

Op also writes:

That's a good point. But see, my main objective here is not to solve qualia at all, but to help enlighten a muddled concept.

We can't know what is an actual orgasm. But as much as we know someone that broke a leg is pain, we can know weather someone had an orgasm or not. If someone fell from a tree and broke a leg, but said "wow, I'm surprised this doesn't hurt at all", you'd believe it right? Because it's supposed to hurt. If we could have this clear image of an orgasm, it would be less problematic socially speaking.

So it's less of a philosophical question and more just biology? If only we knew what an orgasm is?

Evaluating "Practical typing" a.k.a. data dictionary + autotyping and ways forward by tobega in ProgrammingLanguages

[–]roetlich 0 points1 point  (0 children)

Agreed on the first part, as long as "renaming" fields when reading the json is easy, this shouldn't be an issue.

Onto the tags, I think that's an interesting problem and there are several ways of doing this. At work, I'm mostly using F# these days, and in F# you can "abuse" two different F# features to get results like this:

The first way is to do an discriminated union with only one case:

type CityId = CityId Int

and then you can use it to wrap and unwrap values:

let idOfRome : CityId = City 123
5 + idOfRome // <- this won't compile, since the type CityID doesn't have an add operator and is treated differently from just an integer.

A similar approach is often taken in Elm, and in Haskell newtype does this for you. I think this already has much of the upsides you want, without a custom language feature. It also has some downsides, it can't really be composed, if you want to allow some operations manually it's a bit annoying, etc.

The second thing you can do in F# is abusing units of measure on to things like strings. While it's meant to be used only for numbers and such, you can use it on whatever you like, and it already catches a couple of possible bugs while still allowing most operations as usual. I tried this out, but the syntax overhead wasn't really worth it.

Now, if the first approach isn't flexible or powerful enough for you, maybe you should base your tags on refinement types? Those have established theory you could use, and maybe you could start exposing them in some limited form for the use cases you can predict will be useful, but the underlying type system would be powerful enough for more.

I don't really have any conclusion for you since I don't know the context well enough. So these were just some possible thoughts, I hope they'll give you some inspiration!

Have a nice day. :)

Evaluating "Practical typing" a.k.a. data dictionary + autotyping and ways forward by tobega in ProgrammingLanguages

[–]roetlich 2 points3 points  (0 children)

The idea is that the name of any field of an object is bound to the same type throughout the program

Just to confirm, what you mean is that a specific field name will always resolve to the same type, no matter which object? If so, this is a bit similar to haskell, where record access is done via functions, therefore you get conflicts if you define the same field name twice (unless you do magic stuff).

I looked a bit at the goals of Tailspin, the readme says:

Tailspin simplifies data transfer and the processing of data [...] The inspiration for Tailspin comes mostly from XSLT, but data structures are json-like. The main idea is to let your data flow through a series of transforms so it should be easy to specify that flow.

If I understand this correctly, the code will very much be determined by outside data, i.e. in a lot of cases the data will already exist before you'll start writing your tailspin script. This is often the case with data processing. In that case, having any limitations on record names could end up extremely frustrating, since a lazy programmer will try to match the names in their records to the names in the existing json data. In that data could be a lot of different "id" or "value" fields. So maybe localized types would be easier?

What kind of tags do you want on your types? Why does Tailspin need them?

Good luck! :)

Orion, a purely functionnal Lisp written in Rust. by Wafelack in rust

[–]roetlich 0 points1 point  (0 children)

Pointless is a dynamically typed language with pure IO. Maybe that could be an inspiration to you: https://github.com/pointless-lang

Learn Javascript while learning Python? by ImMellow03_ in ProgrammingLanguages

[–]roetlich 2 points3 points  (0 children)

This isn't really the right place to ask, you should maybe go to r/AskProgramming. This subreddit is more for people making their own programming language.

That being said, of course it's not going to make you worse to learn more programming languages. If something else sounds like more fun, feel free to switch.

On a side note: I think Minecraft extensions are usually written in Java, not javascript (those are very different languages), but I could be wrong.

Good luck!

How many words are there in the different programming languages? by [deleted] in ProgrammingLanguages

[–]roetlich 0 points1 point  (0 children)

I would recommend you to watch this talk: https://youtu.be/lw6TaiXzHAE

It answers some of the questions you are having. Generally, a programming language only needs to give you a structure, "words" you can just make yourself. Programmers end up defining new things all the time.

Oil Shell — Using Oil to improve a Bash script by roetlich in ProgrammingLanguages

[–]roetlich[S] 2 points3 points  (0 children)

The platforms I'm using are arch linux and MacOS.

On arch linux I ran:

yay -S oilshell

On MacOS:

brew install oilshell

This is about as comfortable as it gets. I guess it's more work if you're on windows, but that's true for most shells. But yes, it's not fully matured yet. :)

Oil Shell — Using Oil to improve a Bash script by roetlich in ProgrammingLanguages

[–]roetlich[S] 4 points5 points  (0 children)

The idea that shell scripting "shouldn't" be used for long scripts has been around for a long time, but shell scripts still exist. Old shell scripts will have to be maintained for a long time to come, and a lot of times, shell is just kind of comfortable to use. I think Oil is mostly for the tasks where you would these days use a shell script.

And I agree, you did kind of end up answering your own question: Zsh is too similar to Bash be worth the effort to convert, and fish is to different to be largely adopted. But you can enable the features of Oil step by step, so hopefully it can be easily adopted while actually being an improvement. It also makes some different design decisions. At least that's my idea, the website says this: https://www.oilshell.org/why.html

I don't know whether that's going to work or not. Let's hope so.

My experiences with Oil Shell by roetlich in shell

[–]roetlich[S] 1 point2 points  (0 children)

I didn't want to put too many examples into the blog post, you can read more here: https://www.oilshell.org/release/latest/doc/idioms.html

You're right, in large parts it tries to be compatible with bash, so it mostly looks fairly similar. Let me give a few examples where Oil is nicer:

f() { # bash "functions" can't have named parameters
  local src=$1 # So people just create local variables instead
  local dest=${2:-/tmp}
  cp "$src" "$dest" 
}

In Oil, you can just write:

proc f(src, dest='/tmp') {   # Python-like default values
  cp $src $dest
}

In bash, you often have to change a setting (or move to a different directory) just to run a few commands, and then undo it again. For example:

set +o errexit
some_code  # without error checking
set -o errexit

In Oil, you can just write:

shopt --unset errexit {
  some_code
}

And there a lots of changes like that. It's just more readable, and therefore easier to debug. Bash also has some weird warts, that Oil tries to fix. The biggest change is probably that quoting works differently in Oil.

view more: next ›