71–80 of 113 posts
This is the promised land. Remember hearing how good code re-use is? Now it's here.
Maybe we should be more creative in our application's core functionalities, should we not?
Earlier quoted context omitted.
My current project has so far required me to know about Python, Django, Google App Engine and it's datastore, XHTML, CSS, JQuery, Javascript, JSON, and a clutch of XML schema, APIs and the like. This is the price you pay for being able to work with other people. If you never wanted to reuse anyone else's code or talk to anything else on the Internet, you would not need to know any of this. To stand on the shoulders o…
I think you missed the main thrust of his complaint: back when everyone was hacking in FORTRAN and COBOL, you really didn't need to know much more than the language, its standard library, and stuff specific to the problem you were solving. At worst maybe you'd have to learn BLAS and LAPACK if you were doing numerical stuff. The APIs/overhead/junk memorization situation has been steadily worsening since then. But at l…
The problem is that today we demand much more than what those earlier tools can give us. Such demands result in an inevitable (?) increase in complexity of the aggregate toolset. The tools are capable of more, and give you more options. So it seems that learning and using those tools effectively would be more challenging.
But it's not a one-way street. Along with this increase in complexity have been efforts to simplify, streamline, and structure these tools and ease their use. But both the demand for increased ease of learning/use and the demand for power are moving targets. Hopefully with time both could be maximized. We're just not there yet. Remember, computer science is still in its infancy.
Earlier quoted context omitted.
Sql isn't more than that. That's the whole beauty of relational programming, you only have to write queries and views, and this simple abstraction does most of the work that you need to do (with pl/sql or t-sql it is turing complete and you don't even need to leave the rdbms).
I don't get why some people keep praising SQL like this. SQL is great for complex queries that contain valuable logic, but it's not expressive at all when you want to do something trivial. Getting all the attributes of user X is so much more work, and harder to maintain, in SQL than it is in any ORM. "select name, pass, hash, email, realname from user where id = ?" versus session.get("User", x)
Earlier quoted context omitted.
By that example, I meant to highlight the DRY aspect of programming and how I realized, as an early beginner at the age of 15, that frameworks and libraries provide a good foundation so you can focus on more complex issues. The SQL I kept repeating in that application was simple CRUD functions on MySQL tables. I know that SQL is so much more than that.
Sql isn't more than that. That's the whole beauty of relational programming, you only have to write queries and views, and this simple abstraction does most of the work that you need to do (with pl/sql or t-sql it is turing complete and you don't even need to leave the rdbms).
But SQL syntax is a dog. Especially when it's sitting next to real code, wrapped up inside strings and making everything feel dirty.
If you're using an SQL database from within another language primarily just to dump objects and pull them out, and especially if you're doing a lot of it, I have trouble thinking of a situation where you wouldn't prefer to abstract away the SQL bits. Maybe if you're working in a language with built in SQL syntax support? Even then, it's not exactly compact, and you've got quite a bit to do even after you get your results back from the database...
Earlier quoted context omitted.
I don't get why some people keep praising SQL like this. SQL is great for complex queries that contain valuable logic, but it's not expressive at all when you want to do something trivial. Getting all the attributes of user X is so much more work, and harder to maintain, in SQL than it is in any ORM. "select name, pass, hash, email, realname from user where id = ?" versus session.get("User", x)
'SELECT * FROM user WHERE id = ?' OR 'SELECT getUser(?)' presuming you have a stored procedure/function getUser that returns the data you need, and you should (or a view, at least)
Oh dear god, a blasphemer!
The former can cause performance problems if you have blobs as well as being an unnecessary security hole, the latter can cause performance problems over large datasets as it often forces the execution plan away from a set based solution.
My biggest gripe with modern programming is the sheer volume of arbitrary stuff I need to know. My current project has so far required me to know about Python, Django, Google App Engine and it's datastore, XHTML, CSS, JQuery, Javascript, JSON, and a clutch of XML schema, APIs and the like. Don't get me wrong, I'm grateful for all of it, but it just doesn't seem like what I was promised when I followed SICP for the fi…
The situation seems ripe for a disruptive technology to emerge.
What happened is the we finally hit "the dream" of building software out of large building blocks instead of having to reinvent screws and bolts for every project. The lack of fun is, in my opinion, a side effect of using weak languages that force us to write boilerplate and ceremony along with using half-baked non-Turning complete XML languages (don't forget the "L" in "XML" stands for "language").
"screws and bolts... non-Turning (sic) complete" Pun intended?
Earlier quoted context omitted.
Last I checked, BOA in ATL couldn't find enough super good math/finance/C++ programmers, for instance.
It's because the people that are good with math, finance, and programming don't want to use C++ (or live in Atlanta). Remove the C++, and it becomes much easier to find people. Look at how successful companies like Jane Street Capital are in recruiting, for example, even though the pool of people that know OCaml is much smaller than the pool of people that know C++. (My experience with people that know math and finan…
My biggest gripe with modern programming is the sheer volume of arbitrary stuff I need to know. My current project has so far required me to know about Python, Django, Google App Engine and it's datastore, XHTML, CSS, JQuery, Javascript, JSON, and a clutch of XML schema, APIs and the like. Don't get me wrong, I'm grateful for all of it, but it just doesn't seem like what I was promised when I followed SICP for the fi…
This is precisely why I think I enjoy developing for the iPhone more than web development. Yes, Cocoa is a massive library, but it has 99% of the things that I need. I think in objective-c and cocoa. When it comes to web development I'm doing 100's of tiny little things in 2 different languages with 2 different markups to get something done.
We were talking about why some people love working in Objective-C and why others abhor it and came to the general conclusion that it is more of a philosophical issue than a technical one.
That the bits given to you by Cocoa provide the minimum functionality required while the frameworks of other environments try to cover every piece of functionality imaginable.
The former suits the makers and the latter, the assemblers.
I think there is room for both in this world (although I admit I belong to the first camp) but treating both types of "programmer" the same rubs both the wrong way.