34
submitted 3 weeks ago* (last edited 3 weeks ago) by diy@sh.itjust.works to c/programming@programming.dev

I'm looking for a programming language that can help me build a desktop application for Windows, macOS, and Linux that's not big but not small either. Additionally, I'd like to be able to build a website with the same language. I've been considering Ruby, Python, Golang and JavaScript. Python seems to be mainly used for scripting and ai, so I'm not sure if it's the best fit. JavaScript has a lot of negative opinions surrounding it, while Ruby sounds interesting. Can anyone recommend a language that meets my requirements?

you are viewing a single comment's thread
view the rest of the comments
[-] FizzyOrange@programming.dev 0 points 1 week ago

Oh really? How would an IDE go-to-definition on x.bar in this code?

def foo(x):
  return x.bar

Best it can do is heuristics and guesswork.

[-] tyler@programming.dev 0 points 1 week ago* (last edited 1 week ago)

By using the AST? Do you really not know how languages work? I mean seriously, this is incredibly basic stuff. You don’t need to know the type to jump to the ast node location. Do you think that formatters for dynamic languages need to know the type in order to format them properly? Then why in the world would you need it to know where to jump to in a type definition!?!

Edit: also in the case of Ruby, the entire thing runs on a VM which used to be YARV but I think might have changed recently. So there’s literally bytecode providing all the information needed to run it. I highly recommend reading a book about how the Ruby internals work since you seem to think you understand but it’s quite clear you don’t, or for some reason think “jump to” is this magical thing that requires types.

[-] FizzyOrange@programming.dev 0 points 5 days ago* (last edited 5 days ago)

I think you're getting a bit confused. How do you know where x's type is defined and therefore where x.bar is defined if you don't know what type x is? It's literally impossible. Best you can do is global type inference but that has very big limitations and is not really feasible in a language that wasn't designed for it.

Do you think that formatters for dynamic languages need to know the type in order to format them properly? Then why in the world would you need it to know where to jump to in a type definition!?!

Not sure if that is a serious question, but it's because formatting doesn't depend on the type of variables but going to the definition of a field obviously depends on the type that the field is in.

Maybe my example was not clear enough for you - I guess it's possible you've never experienced working intellisense, so you don't understand the feature I'm describing.

class A:
  bar: int

class B:
  bar: str

def foo(x):
  return x.bar

Ctrl-click on bar. Where does it jump to?

[-] tyler@programming.dev 1 points 5 days ago

Not sure if that is a serious question, but it’s because formatting doesn’t depend on the type of variables but going to the definition of a field obviously depends on the type that the field is in.

formatting does depend on the type of variables. Go look at ktfmt's codebase and come back after you've done so...

Maybe my example was not clear enough for you - I guess it’s possible you’ve never experienced working intellisense, so you don’t understand the feature I’m describing.

Lol, nice try with the insult there. I code in Kotlin, my intellisense works just fine. I just think you're quite ignorant and have no clue what you're actually talking about.

Ctrl-click on bar. Where does it jump to?

it gives you an option, just like if it was an interface. Did you actually try this out before commenting? Guessing not. And how often are you naming functions the exact same thing across two different classes without using an interface? And if you were using an interface intellisense would work the exact same way, giving you the option to jump to any of the implementations.

I'm sorry, but you clearly haven't thought this out, or you're really quite ignorant as to how intellisense works in all languages (including Ruby, and including statically typed languages).

[-] FizzyOrange@programming.dev 1 points 5 days ago

formatting does depend on the type of variables. Go look at ktfmt’s codebase and come back after you’ve done so…

I skimmed it. It appears to visit the AST of the code and format that, as any formatter does. ASTs have not been type checked.

Can you give an example?

it gives you an option, just like if it was an interface. Did you actually try this out before commenting?

Precisely! It doesn't know the answer so it has to guess, or make you guess.

And how often are you naming functions the exact same thing across two different classes without using an interface?

You mean how often does the same field name come up more than once? All the time obviously! Think about common names like id, size, begin, children, etc. etc.

I’m sorry, but you clearly haven’t thought this out, or you’re really quite ignorant as to how intellisense works in all languages (including Ruby, and including statically typed languages).

I'm sorry but you clearly haven't thought this through, or you're just happy to ignore the limitations of Ruby. I suspect the latter. Please don't pretend they aren't limitations though. It's ok to say "yes this isn't very good but I like Ruby anyway".

this post was submitted on 07 Jun 2024
34 points (88.6% liked)

Programming

16207 readers
531 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS