|
Dr Monkeysee posted:easily but not elegantly. wrapping all your types in a struct is awkward and obscures your intent. like, size_t has deliberate semantics beyond "an unsigned integer of a certain size" and it's annoying that if i write a function that takes a size_t it'll also blindly accept a uint64_t or a long long or whatever (even aside from the fact that it'll accept *different* types on a different architecture). Wrapping types doesn't have to be awkward unless it's stuff you need operators to work on, which is admittedly the case in your example. C++ obviously makes this easier. -Wconversion can also be nice but it's a bit impractical to introduce to a large existing project.
|
#
?
Jun 9, 2016 22:52
|
|
|
|
| # ? Jun 11, 2024 23:03 |
|
|
tef posted:btw python has a type checker now it's pretty bad, though, especially w/ regards to forward references
|
|
#
?
Jun 9, 2016 22:58
|
|
|
Zaxxon posted:the best case I've ever found is when you want to describe a sequence of functions where they should have the type (whatever the previous one gave me)->(whatever the next one wants) discoverable at run time. I've written some data shoveling tools that dynamically spun up new processes to do ETLS based on watching zookeeper for job configs we had a system that did stuff like that. my coworker made an Op interface that could be chained via input/output so every time we needed a new thing we wrote a new ParseXMLOp or ShitPantsOp or wahtever i guess it wasnt really a list anymore
|
|
#
?
Jun 9, 2016 23:00
|
|
|
Zaxxon posted:the best case I've ever found is when you want to describe a sequence of functions where they should have the type (whatever the previous one gave me)->(whatever the next one wants) discoverable at run time. I've written some data shoveling tools that dynamically spun up new processes to do ETLS based on watching zookeeper for job configs FWIW you can solve this sort of problem pretty satisfactorily with static types in modern C++ without too much effort or introducing excess dynamic checks, using the same kind of type erasure implementations of std::function do. You can see something very similar in the chaining support added by the current futures TS.
|
|
#
?
Jun 9, 2016 23:06
|
|
|
Ralith posted:FWIW you can solve this sort of problem pretty satisfactorily with static types in modern C++ without too much effort or introducing excess dynamic checks, using the same kind of type erasure implementations of std::function do. You can see something very similar in the chaining support added by the current futures TS. I wager you could even do it in Haskell or OCaml or something like that It would just be a pain.
|
|
#
?
Jun 9, 2016 23:23
|
|
|
Zaxxon posted:I wager you could even do it in Haskell or OCaml or something like that It would just be a pain. it's been done, it's called hlist and nobody really uses it cause there are usually better options
|
|
#
?
Jun 10, 2016 00:34
|
|
|
or dynamic in c#
|
|
#
?
Jun 10, 2016 00:37
|
|
|
tef posted:btw python has a type checker now no you see it's not the same because
|
|
#
?
Jun 10, 2016 00:50
|
|
|
Zaxxon posted:I wager you could even do it in Haskell or OCaml or something like that It would just be a pain.
|
|
#
?
Jun 10, 2016 02:13
|
|
|
if you cant nave heterogenous lists in your dynamic lang then what's the point even/?
|
|
#
?
Jun 10, 2016 03:07
|
|
|
In a dynamic lang you might as well allow your lists to be heterogenous since it makes them more flexible and it's not like there's a compiler to catch type errors anyways. MonocQc, I thought your posts over the last few pages were pretty interesting and even though I would rather use the giant ADT, I could understand why someone would prefer the big heterogenous list of options. Also the chained function thing was interesting, whoever posted that.
|
|
#
?
Jun 10, 2016 03:25
|
|
|
tef posted:dynamic typing is great in the small, static typing is great in the large, what's the loving issue dynamic typing is bad everywhere.
|
|
#
?
Jun 10, 2016 03:27
|
|
|
the best part of static typing is it makes discovery trivial
|
|
#
?
Jun 10, 2016 03:29
|
|
|
the only defense of dynamic typing is morons still using text editors to write code complaining about keystrokes
|
|
#
?
Jun 10, 2016 03:30
|
|
|
what if you had something like unsafe in rust but for types oh wait that would just be a go interface
|
|
#
?
Jun 10, 2016 03:36
|
|
|
casting to object
|
|
#
?
Jun 10, 2016 03:38
|
|
|
MALE SHOEGAZE posted:what if you had something like unsafe in rust but for types idk what that is cause I don't use bad languages, but in c# you can do ^^^^ and theres also a dynamic type. the only time its ever really used is in MVC examples of the viewbag and in SignalR for calling javascript methods from c#. imo they don't really need the dynamic stuff in signalr and it could be done better.
|
|
#
?
Jun 10, 2016 03:43
|
|
|
I don't know for you guys but my dynamic language of choice has a type checker that has parametric types and does inference and poo poo 
|
|
#
?
Jun 10, 2016 04:02
|
|
|
in that case why don't you run the type checker before you run your program? then you don't have to call it a dynamic language anymore, and you'll benefit from better compiler performance and static correctness guarantees
|
|
#
?
Jun 10, 2016 04:43
|
|
|
isn't the erlang thing more like a linter, it tells you where the types look wrong but you can still run the program and it might even work
|
|
#
?
Jun 10, 2016 08:14
|
|
|
JewKiller 3000 posted:in that case why don't you run the type checker before you run your program? then you don't have to call it a dynamic language anymore, and you'll benefit from better compiler performance and static correctness guarantees
|
|
#
?
Jun 10, 2016 08:18
|
|
|
MononcQc posted:I don't know for you guys but my dynamic language of choice has a type checker that has parametric types and does inference and poo poo I like dialyzer and typescript
|
|
#
?
Jun 10, 2016 08:47
|
|
|
Soricidus posted:isn't the erlang thing more like a linter, it tells you where the types look wrong but you can still run the program and it might even work It's a full blown type checker, but instead of implementing Hindley-Milner or some other system like that, it does success types. Rather than doing an axiomatic analysis (start with the bottom type, allow things and expand it when you prove they work), it goes the other way around and starts with the 'term()' or 'any()' type and goes for subtypes of it as constraints are discovered in you program (i.e. if you are using additions, the inferred type is no longer allowing lists, tuples, binaries, etc., but only numeric types). When it finds an error, it therefore knows for sure there is a problem. So rather than going "here are all the unprovable types", it goes "here are all the provably wrong types" which means you swap false positives and correctness for no false positive and possibly letting some errors through. This was due to their objective: quote:Our main goal is to make uncover the implicit type information in Erlang code and make it explicitly available in programs. Because of the sizes of typical Erlang applications, the type inference should be completely automatic and faithfully respect the operational semantics of the language. Moreover, it should impose no code rewrites of any kind. The reason for this is simple. Rewriting, often safety critical, applications consisting of hundreds of thousand lines of code just to satisfy a type inferencer is not an option which will enjoy much success. However, large software applications have to be maintained, and often not by their original authors. By automatically revealing the type information that is already present, we provide automatic documentation that can evolve together with the program and will not rot. We also think that it is important to achieve a balance between precision and readability. Last but not least, the inferred typings should never be wrong. Dialyzer is also able to do stuff like purity analysis (they haven't used it, but there's ideas around turning the type inference to be more stricter when a code subset is known to be pure for example), or race condition detection, and comes with a second tool (typer) which looks at code and generates type signatures for you. I do believe some of that inference is used in HiPE to generate native code that optimizes code paths deemed safe. E: an interesting bit in there is that the type checker finds more errors the larger the programs are; they do very little efficient work on small programs as there is little information to be used to refine types. MononcQc fucked around with this message at 16:46 on Jun 10, 2016 |
|
#
?
Jun 10, 2016 16:40
|
|
|
is there a hipster relational query language that is like sql but good? i've been hitting cases of things that should be easy but turns out to require bolt-on-feature x that is only supported in some random 25% of sql servers someone must have made something based more on relational algebra and less on cobol
|
|
#
?
Jun 16, 2016 07:35
|
|
|
suffix posted:is there a hipster relational query language that is like sql but good? yea its here yo (20%)yo (73%) yo/74%)
|
|
#
?
Jun 16, 2016 08:04
|
|
|
hipster database programming is just doing manual joins in ruby on a non-performant object store with no transactional guarantees
|
|
#
?
Jun 16, 2016 08:40
|
|
|
apparently it's called tutorial d, or maybe business system 12 if you want to go retro kind of interesting but probably completely pointless since nothing supports it http://c2.com/cgi/wiki?QueryLanguageComparison http://dcs.warwick.ac.uk/~hugh/TTM/Importance-of-Column-Names.pdf is basically a critique of sql i can agree with some of it, but lol at advocating natural joins, and double lol at doing it on the same page you're using 'E#' as a column name how much of an academic do you have to be to not anticipate the accidental name collisions from that
|
|
#
?
Jun 16, 2016 09:36
|
|
|
datalog should come back
|
|
#
?
Jun 16, 2016 10:31
|
|
|
in the same vein there's andlquote:Andl is a New Database Language designed to replace SQL and then go beyond. it being written in C# and not being ported to ms mono, and also forbidding commercial use has stymied my plans to rely on a project developed by one .NET graybeard.
|
|
#
?
Jun 16, 2016 10:56
|
|
|
Cybernetic Vermin posted:datalog should come back Datomic is sorta datalog and fully sick, http://www.datomic.com To bad it's expensive and not open source
|
|
#
?
Jun 16, 2016 14:22
|
|
|
don' t try and write database-agnostic SQL like, T-SQL and PL/SQL and pgSQL are all fine. they're also similar ENOUGH that an ORM can generate code for them like dialects. but 'ANSI SQL' is essentially a nonsense
|
|
#
?
Jun 17, 2016 14:24
|
|
|
Gul Banana posted:don' t try and write database-agnostic SQL just order an ansi standard za
|
|
#
?
Jun 17, 2016 15:27
|
|
|
SQL is not a language but rather a big pile of special cases
|
|
#
?
Jun 18, 2016 17:22
|
|
|
i enjoy writing sql
|
|
#
?
Jun 18, 2016 19:03
|
|
|
MALE SHOEGAZE posted:i enjoy writing sql me too. it is a sickness the day i learned about CTE's in postgres was legitimately a highlight of my professional career
|
|
#
?
Jun 18, 2016 19:20
|
|
|
MALE SHOEGAZE posted:i enjoy writing sql
|
|
#
?
Jun 18, 2016 20:25
|
|
|
the talent deficit posted:me too. it is a sickness i dont doubt that postgres contains chronic traumatic encephalopathy
|
|
#
?
Jun 18, 2016 22:27
|
|
|
sql is poo poo and old-school databases are poo poo but databases in general and query languages with some sound logical basis are good fun to work with
|
|
#
?
Jun 18, 2016 22:31
|
|
|
Bloody posted:i dont doubt that postgres contains chronic traumatic encephalopathy
|
|
#
?
Jun 18, 2016 22:35
|
|
|
|
| # ? Jun 11, 2024 23:03 |
|
|
SQL is cool and good reminder: https://wiki.postgresql.org/wiki/Mandelbrot_set
|
|
#
?
Jun 18, 2016 22:51
|
|
