|
b0lt posted:"sufficiently smart jit" is just as handwavey as "sufficiently smart compiler" (strongtalk, hotspot, luajit, spring to mind)
|
# ? Aug 26, 2014 04:55 |
|
|
# ? Jun 12, 2024 07:40 |
|
tef posted:scala is fiendishly complex, and performant scala is closer to java than idiomatic scala. scala is fiendishly complex if you want it to be. in daily use it's java with a repl and a compiler that's not stupid. if complexity is really the enemy, there is also groovy
|
# ? Aug 26, 2014 04:56 |
|
MALE SHOEGAZE posted:the thing i hate the most about ruby atm is that it strongly encourages you to just use a hash as your only argument, and people will call it the options hash, and then the entire method is built out of options that maybe arent actually optional anymore. but good luck looking at the method signature to figure that out because it's just foo(opt={}). they fixed this in 2.0 with keyword arguments http://brainspec.com/blog/2012/10/08/keyword-arguments-ruby-2-0/
|
# ? Aug 26, 2014 04:59 |
|
Subjunctive posted:I don't know why you couldn't JIT ruby like you do JS and Lua and PHP -- what parts would be worse? and if you can JIT you can do AOT. you'll have a support runtime, but so do Java and C#. js and lua are not germane. i know for sure that js is a much more consistent, streamlined language than ruby or python. it was consciously designed by one person. the semantics are difficult to grasp (because it's nuts) but it's less difficult to implement. php is a more apt comparison. existing compilers for php either a.) produce really loving slow output, just like php (e.g. caucho/resin, facebook's first attempt) or b.) abandon 100% php compatibility as a goal (facebook's second attempt) people have put a shitton of work into ruby performance, but they've put it into interpreters, where actual gains can be made. jruby and mri 2.x are both much faster than old school ruby. still slow, but half as slow
|
# ? Aug 26, 2014 05:00 |
|
Notorious b.s.d. posted:in daily use it's java with a repl and a compiler that's not stupid also some nice semantics around pattern matching/partial functions amongst others. I don't get super deep into the type system stuff with Scala and I'll say there's a lot of conveniences to it that feel nice.
|
# ? Aug 26, 2014 05:01 |
|
Notorious b.s.d. posted:js and lua are not germane. i know for sure that js is a much more consistent, streamlined language than ruby or python. it was consciously designed by one person. the semantics are difficult to grasp (because it's nuts) but it's less difficult to implement. Can you give an example of something in Ruby that's not amenable to JIT? I can imagine things like mutable caller frames making certain optimizations harder, but I can't figure out why "emit machine code that operates on the same representations" as a baseline compiler isn't feasible, especially for a JIT that can punt back to the interpreter if someone touches the stupid. the HHVM team has committed to complete Zend compatibility now, and there are a lot of relevant fixes going in, but I'm sure there'll be some adventures. none of them seem to think that there are pieces that are impossible, though, just annoying. of course Zend PHP isn't completely compatible with itself version to version, so...
|
# ? Aug 26, 2014 05:36 |
|
GrumpyDoctor posted:i like f# because using it is like looking into the future of c# and vb.net that's because you're looking at ocaml
|
# ? Aug 26, 2014 07:46 |
|
GrumpyDoctor posted:i like f# because using it is like looking into the future of c# and vb.net and also the closest i can get to haskell while still being able to use it for work coffeetable fucked around with this message at 07:56 on Aug 26, 2014 |
# ? Aug 26, 2014 07:54 |
|
just use Scala
|
# ? Aug 26, 2014 08:07 |
|
i don't know much about scala. java is in many ways a better thought-out language than c#, and there're more than a few bits of f# that just seem to have been nailed on for shits and giggles. thing is, there's some pretty convincing arguments to stay in the .net ecosystem:
|
# ? Aug 26, 2014 08:23 |
|
Shaggar posted:java is great because it forces everyone to use those standards or leave and go back to their lovely p-langs. all the poo poo p-langers hate about java is what makes it the best language.
|
# ? Aug 26, 2014 08:42 |
|
ShadowHawk posted:Python forces people to use more or less the same formatting standard which is pretty nice gofmt was a pretty good idea too
|
# ? Aug 26, 2014 08:56 |
|
go isnt dead yet?
|
# ? Aug 26, 2014 10:09 |
|
fleshweasel posted:otoh you could be using c# which is basically java but better in literally every aspect same, except worse. Mr Dog posted:e: bbcode sux
|
# ? Aug 26, 2014 12:09 |
|
Shinku ABOOKEN posted:go isnt dead yet? Go looks neat to my scrub eyes. It seems more accessible than C++ but that is prolly just the hype
|
# ? Aug 26, 2014 12:38 |
|
syntaxrigger posted:more accessible than C++
|
# ? Aug 26, 2014 12:46 |
|
Damiya posted:also some nice semantics around pattern matching/partial functions amongst others. it feels like c++ all over again
|
# ? Aug 26, 2014 12:54 |
|
MALE SHOEGAZE posted:how much would you need to sacrifice from a language like ruby to make it a useful language? your children, at the altar of bha'al
|
# ? Aug 26, 2014 14:16 |
|
Mr Dog posted:same, except worse. what about properties
|
# ? Aug 26, 2014 14:50 |
|
Mr Dog posted:same, except worse. valid criticisms except for base class matching a file name, that's a grognardy clown complaint
|
# ? Aug 26, 2014 14:51 |
|
python was good at 2.7 and is sweet at 3.4 and will continue to become better in the future and it makes me happy
|
# ? Aug 26, 2014 14:54 |
|
Notorious b.s.d. posted:i know for sure that js is a much more consistent, streamlined language than ruby or python.
|
# ? Aug 26, 2014 14:55 |
|
Mr Dog posted:same, except worse. thanks for this post -- most people seem to say that c# has the better language and java has the better standard library, and i'm interested in understanding why people prefer one or the other
|
# ? Aug 26, 2014 15:25 |
|
I'll play the tbc and say that static typing is way overrated when it comes about catching errors. I'm p sure any kind of trivial testing will catch most of these errors dynamic typing is great, here's what's wrong in other p-langs: - in javascript (and php I guess) the combination of weak + dynamic typing brings you a long list of stupid gotchas - in ruby people hate exceptions or something and like to return nil instead I guess this is why stuff like tdd is such a big deal in javascript and ruby. yes, in both of these cases I feel like a static typed lang would be more adequate. but not with python or racket, I swear to god I'll never use this type annotations bullshit once or typed racket again
|
# ? Aug 26, 2014 15:39 |
|
dynamic4lyfe
|
# ? Aug 26, 2014 15:39 |
|
dynamic typing is garbage for garbage people.
|
# ? Aug 26, 2014 15:41 |
|
Symbolic Butt posted:I'll play the tbc and say that static typing is way overrated when it comes about catching errors. I'm p sure any kind of trivial testing will catch most of these errors why the gently caress do i want to write hundreds of trivial tests in a separate file instead of expressing my invariants directly, inside the code? that is the most rear end-backwards thing
|
# ? Aug 26, 2014 15:48 |
|
Symbolic Butt posted:I'll play the tbc and say that static typing is way overrated when it comes about catching errors. I'm p sure any kind of trivial testing will catch most of these errors trivial testing that, maybe, the compiler could carry out for you?
|
# ? Aug 26, 2014 15:57 |
|
when I say trivial test, I mean any kind of test like you'll need to check if factorial(5) == 120 anyway, if you messed something that static typing would catch then just this test would immediately catch the error because it'd return something really stupid instead I'm not writing asserts around the functions or something
|
# ? Aug 26, 2014 16:01 |
|
if you have a function with the signature void foo(filtered_input bar) and call it with an argument of type string or of type unfiltered_input, the compiler gives you an error and prevents a potentially bad bug good luck catching that with typical unit testing
|
# ? Aug 26, 2014 16:03 |
|
Symbolic Butt posted:- in ruby people hate exceptions or something and like to return nil instead would people like to post some examples of ruby core doing this? i write ruby for a living and i don't encounter this much
|
# ? Aug 26, 2014 16:10 |
|
Subjunctive posted:Can you give an example of something in Ruby that's not amenable to JIT? I can imagine things like mutable caller frames making certain optimizations harder, but I can't figure out why "emit machine code that operates on the same representations" as a baseline compiler isn't feasible, especially for a JIT that can punt back to the interpreter if someone touches the stupid. and it's worse than you think. e.g. closures retain the ability to edit their enclosing frame for as long as they exist. Subjunctive posted:the HHVM team has committed to complete Zend compatibility now, and there are a lot of relevant fixes going in, but I'm sure there'll be some adventures. none of them seem to think that there are pieces that are impossible, though, just annoying. of course Zend PHP isn't completely compatible with itself version to version, so... well "not impossible but annoying" includes all the cases that are hilariously slow, or require it to stop the world while it compiles and loads a new module on the fly. common lisp always had the problem that while it was very possible to write a fast CL compiler, people once expected to be able to load/generate new code at runtime on a regular basis, not as a rare event. 80s and 90s CL implementations solved this by including a bytecoded interpreter IN ADDITION TO the compiler modern CL systems omit the bytecode interpreters, because codebases that abuse code generation have become rare. CL implementors have concluded that it's better to implement that case in an incredibly slow way (compile poo poo on the spot) in order to keep their implementation simple in ruby, generated and runtime-modified code is 100% completely normal. method_missing and refinements are as bad as perl's autoload and BEGIN blocks.
|
# ? Aug 26, 2014 16:13 |
|
Symbolic Butt posted:I'll play the tbc and say that static typing is way overrated when it comes about catching errors. I'm p sure any kind of trivial testing will catch most of these errors yes, some kind of way to test your code...statically...all at once
|
# ? Aug 26, 2014 16:17 |
|
Static type systems are way more helpful in helping you design your software around them. And you must embrace the types if you want to benefit from it. They let you express the broad ideas about the data that your app operates on, and makes sure you didn't make any mistake in how the different pieces fit together. If you get into the case where you decided that Distance is an int, you still run into the issue that you're going to eventually plug in imperial units with metric units and explode a shuttle. You really have to be careful about building a type zoo rich enough to actually represent the problems you're working on and the data you're using in order to prevent errors with types at a higher level than the primitives given to you by the language. If you go lazy on your usage or whatever, you don't necessarily cover the most important type errors, you'll just cover the most obvious ones, along with the same false confidence you'd get from tests.
|
# ? Aug 26, 2014 16:24 |
|
hepatizon posted:would people like to post some examples of ruby core doing this? i write ruby for a living and i don't encounter this much Array#first
|
# ? Aug 26, 2014 16:29 |
|
MononcQc posted:Static type systems are way more helpful in helping you design your software around them. And you must embrace the types if you want to benefit from it. They let you express the broad ideas about the data that your app operates on, and makes sure you didn't make any mistake in how the different pieces fit together. what are your thoughts on passing a tag+data tuple to a process/task/whatever and letting the process/task/whatever crash when it encounters a tag it doesn't recognize vs sending the message without a tag and pattern matching on the type of the data? (if what i just said makes sense)
|
# ? Aug 26, 2014 16:36 |
|
FamDav posted:Array#first sure, array indexing and hash lookups count as an example, although i personally find this convention works great for me. any others? hepatizon fucked around with this message at 16:41 on Aug 26, 2014 |
# ? Aug 26, 2014 16:37 |
|
Otto Skorzeny posted:what are your thoughts on passing a tag+data tuple to a process/task/whatever and letting the process/task/whatever crash when it encounters a tag it doesn't recognize vs sending the message without a tag and pattern matching on the type of the data? (if what i just said makes sense) I prefer to wrap that stuff in a function call that sends the data to the process (but is owned in the process' module). Do the verification and assertions there, outside of the more critical/stateful process, and if something is wrong, you crash the caller, not the process. If the process crashes, then you know you've forgotten an important assertion, but hopefully it doesn't need to ever crash on type stuff. Move all dynamic type verifications, assertions, etc. to the edge of the system (so for a process, to the caller) and assume that what makes it inside is safe. This makes poo poo easier to test (whether through unit tests, integration tests, property-based tests, etc.), and will also make it much easier to play with type checkers like Dialyzer, which can't really track types over an untyped mailbox, but will do it fine otherwise. Doing that also makes it much easier to reason about your system. Once you've cleared all the thinking about "am I getting the right kind of data?" out of the way, you're free to reason about the task to actually accomplish and that lets you keep far less stuff inside your head that's not directly relevant to the problem. At this point, tags are useful to have because they more or less represent types themselves (except they're just enacted at runtime) and make it easy to crash early, and Dialyzer will have an even easier time figuring that poo poo out that way. E: I make heavy assumptions of Erlang due to using processes, message passing, pattern matching, tag/tuples, etc. Maybe that was wrong? MononcQc fucked around with this message at 16:51 on Aug 26, 2014 |
# ? Aug 26, 2014 16:47 |
|
yeah, using types to represent narrower classes of data state rather than just representation can be really valuable, but you don't see it very often. Java doesn't have a different type for UnvalidatedCertificate vs ValidatedCertificate, AFAIK. so you're writing tests, and those tests will catch string-vs-int representation mismatch as well. there's a good paper I'll try to dig up. I like type systems as compiler-enforced documentation, but they're pretty underused from the perspective of actually preventing bugs statically.
|
# ? Aug 26, 2014 16:47 |
|
|
# ? Jun 12, 2024 07:40 |
|
FamDav posted:Array#first wait what does Array#first [Nil] return then or whatever the syntax is
|
# ? Aug 26, 2014 16:48 |