171–180 of 384 posts
If you're into this sort of thing, definitely check out the ICFP Programming Contest -- take next Friday off and join in on the fun! https://icfpcontest2019.github.io/
Earlier quoted context omitted.
How do you like D btw? Is it worth learning for a c++ programmer? I find the syntax very appealing.
Walter Bright is (along with Andrei Alexandrescu - which should be a good enough reason if you like c++) the BDFL of D. D won't get you hired (probably), but D is designed with hindsight from a C++ compiler writer and a C++ template wizard: It shows, D is objectively better than C++ is many ways. It's worth checking out, at the very least (It's also not hard to learn, so I say go for it) An example of the power of D:…
On the contrary. Many members of the D community have managed to leverage their D expertise into well-paying jobs. Many industrial D users recruit from the D community.
Earlier quoted context omitted.
How do you like D btw? Is it worth learning for a c++ programmer? I find the syntax very appealing.
Fun fact the person you're replying to is the creator of D, I'm pretty sure he likes it. I've personally played around with D a bit and written maybe 1kloc in it and I like it. It doesn't have good pattern matching or the borrow checker, but it does have much better metaprogramming than Rust. I think a lot of the metaprogramming used in the Python project could also be done basically as easily in D, which is a big ac…
Earlier quoted context omitted.
No matter what, you need a rigorous schema for your data. If you write a complex JS/Python program without doing the equivalent of "come up with the right set of types" then you will have a bad time. I'm sure in the OP here the skilled Python programmer did think carefully about the shapes of her data, she just didn't write it down. To be sure, having to write down those data structure invariants in a rigorous way th…
> But the hard part really is coming up with the invariants, Surely. But if you have to write them down it becomes hard to change them because then you will have to rewrite them, and you may need to do that many times if your initial invariants are not the final correct ones. The initial ones are likely not to be the final correct ones because as you say coming up with the invariants is ... the hard part.
"Their project was 17,211 raw lines, 15k source lines, and 637kb" So a couple of students cranked out 15K lines of code, in basically a subset of their study time, for a single class? I don't doubt they did it, what I doubt is the quality of what they wrote. Because it's 'just a project' it doesn't have to be fully debugged ... But that is a vast amount of code to hand-write over a short period of time. At that level…
Note that project is the outlier for how much code it contained. That team did have the most trouble getting things done on time and fixing all the bugs, so they passed the least tests, as one would expect given how much code their design choices required them to write. I think the causality goes from their design to the line count, not from the line count to worse design, they had to write lots of code to implement…
But - '6 internships' is not quite enough to do this comprehensively, as exhibited by someone blasting out 15K LOC (I'm still reeling at that).
I've worked on a number of projects in C++ and I'm pretty sure that I'm not very good at it, even with many years of experience in other languages, for example.
The authors deserve a lot of credit, but I don't think much can be concluded from this ... it's just not the right situation.
FYI - this kind of comparison is very difficult to do even for the most experienced.
I think the big big result from this study is: "Python: half the size !". A dynamic language like Python is better here, 2x better. I assume similar results would apply to other dynamic languages like JavaScript, Lisp, Smalltalk, Groovy etc. This does not say that static typing should not be used but I think it shows unequivocally that there is a considerable extra development cost associated with static typing. You…
You have to be careful with that.
In a dynamic language your test system is your compiler. It is essentially a domain specific compiler. With a statically typed language, half your tests are already written, and you just have to activate them with a type signature.
For my money the trade off is down to whether forcing structures into a type system and getting the 'free advanced tests' is more advantageous than constructing a domain specific test harness 'compiler' and getting the flexibility of duck typing.
And you only learn that when you run up against the limits of the type system and have to start complicating structures to work around it.
In terms of a rough metric I'd suggest you have to include the test code in both cases to get a fair comparison.
Earlier quoted context omitted.
I agree it's definitely an interesting result and a point in favour of dynamic languages. A caveat is that I'm pretty sure my friend intentionally sacrificed code quality to do it, I don't think you'd find that project as readable and understandable as the others. Another caveat is that you have to be okay with your codebase being extremely magical and metaprogramming-heavy, which many industrial users of dynamic lan…
I've read my share of cryptic JavaScript written by others and in that sense I agree that in multi-person long-term projects static typing no doubt will have its advantages. My hunch is however that what is often overlooked in development with statically typed languages is that it takes considerable time and effort to come up with the right set of types. Many examples are written showing how types almost magically ma…
I've written once here before, this is one of the 'accidental advantages' of TypeScript: you set the compiler 'loose' when you're hacking away, writing quickly, and then 'make it more strict' as you start to consolidate your classes.
I almost don't bother to type something until I have to. Once I see it sitting there for a while, and I know it's not going to change much ... I make it a type.
It's an oddly liberating thing that I don't think was ever part of the objectives of the language, moreover, I can't think of any similar situation in other (at least mainstream) languages.
Static or dynamic typing doesn't matter that much if you can verify your software, and there are many different reasons to choose a particular programming language.
Earlier quoted context omitted.
It's difficult to write a fair comparison without being a fairly competent programmer in each of the languages. The trouble is, if a person is an expert C programmer and then translates it to Python that he's only modestly familiar with, the Python program will look like C. It won't be idiomatic Python. For example, my early Fortran programs looked like Basic. My early C programs looked like Fortran. My early C++ pro…
That is all true. At the same time here the groups were allowed to use the language of their choice. Presumably they chose languages they felt they were competent in. Of course an expert of a given programming language can write much better in it than a novice. But a comparison like this is not necessarily about comparing top-programmers in every language, but average programmers, because we want to know results that…
Only having a few thousand lines of code written in Haskell very much makes you a novice. With that said, writing a compiler in Haskell is actually pretty trivial. It's at the very least considerably easier than most other languages.
Earlier quoted context omitted.
I've read my share of cryptic JavaScript written by others and in that sense I agree that in multi-person long-term projects static typing no doubt will have its advantages. My hunch is however that what is often overlooked in development with statically typed languages is that it takes considerable time and effort to come up with the right set of types. Many examples are written showing how types almost magically ma…
"that it takes considerable time and effort to come up with the right set of types. " I've written once here before, this is one of the 'accidental advantages' of TypeScript: you set the compiler 'loose' when you're hacking away, writing quickly, and then 'make it more strict' as you start to consolidate your classes. I almost don't bother to type something until I have to. Once I see it sitting there for a while, an…
Add type hints at any time, check types at any time. Type hints can also serve purely as hints to programmers and not checked at all.